System and method for bidirectional communication between stylus and stylus sensor controller

ABSTRACT

A method is provided for communication between a host processor and an active stylus via a sensor controller, wherein the sensor controller is coupled to a sensor configured to interact with the active stylus. The method includes generally three steps. First, the host processor transmits a command received from an application operating on the host processor. Second, the sensor controller receives the command from the host processor and forwards the command to the active stylus. Third, the active stylus, in response to the command, operates on the command and transmits a command response to the sensor controller.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority to U.S. Provisional Patent Application No. 62/149,907, entitled “Position Input Method, Position Input System, Sensor Controller and Stylus,” filed Apr. 20, 2015; U.S. Provisional Patent Application No. 62/162,527, entitled “Position Input Method, Position Input System, Sensor Controller and Stylus,” filed May 15, 2015; U.S. Provisional Patent Application No. 62/243,427, entitled “Position Input Method, Position Input System, Sensor Controller and Stylus,” filed Oct. 19, 2015; U.S. Provisional Patent Application No. 62/291,373, entitled “System and Method for Bidirectional Communication Between Stylus and Stylus Sensor Controller,” filed Feb. 4, 2016; U.S. Provisional Patent Application No. 62/152,870, entitled “Position Input Method and Position Input System,” filed Apr. 25, 2015; U.S. Provisional Patent Application No. 62/191,913, entitled “Position Input Method and Position Input System,” filed Jul. 13, 2015; U.S. Provisional Patent Application No. 62/240,984, entitled “Position Input Method and Position Input System,” filed Oct. 13, 2015; and U.S. Provisional Patent Application No. 62/291,356, entitled “Position Input Method and Position Input System,” filed Feb. 4, 2016, the entirety of which are hereby incorporated by reference.

BACKGROUND Technical Field

The present application relates to an active stylus, a sensor controller for a stylus sensor, a host processor to be coupled to the stylus sensor, and a position input system and method based on such stylus, sensor controller and host processor; and more particularly to a position input system and method that utilize a bidirectional communications protocol between the stylus and the sensor controller and between the sensor controller and the host processor.

Description of the Related Art

Various types of styluses are available that allow users to handwrite text and graphics on stylus-sensitive screens (sensors) of electronic devices, such as tablet computers, smart phones, etc. For example, an active electrostatic (capacitive) stylus includes a power source and a signal processor, and transmits signal by providing an electric charge corresponding to the transmission signal to an electrode provided at a tip of the stylus, to thereby cause a change in an electric field at or near a position indicated (pointed to) by the tip. A stylus-sensitive screen (sensor) of an electronic device includes a matrix of X- and Y-electrodes, and the above-described change in the electric field created by the stylus tip induces a corresponding change in an electric charge in the matrix electrodes at or near the stylus tip. A sensor controller coupled to the sensor and/or a host processor of the electronic device detects such change in the electric charge in the matrix electrodes to thereby detect the transmission signal from the stylus. The sensor controller and/or the host processor then determine the position indicated by the stylus on the sensor based on the location of the matrix electrodes that detected the transmission signal.

Different types of active styluses have different stylus capabilities or functions, such as pen (stylus) tip pressure detection capability, how many different levels the pen (tip) pressure can be detected, pen orientation detection capability including pen twist (rotation) detection capability and pen tilt detection capability, different numbers and kinds of barrel buttons (switches) provided on the styluses, etc. Typically, a data format used in communication from a stylus to a sensor controller is rigidly configured in a given stylus-sensor system and incapable of supporting different and expanding variations of stylus capabilities and functions.

While it is possible for each stylus to always transmit its entire capability information to the sensor controller each time the stylus is used with (i.e., enters the sensing zone of) the sensor controller, such transmission of the entire capability information would take up multiple time slots or frames available in a given communications protocol. In a typical situation where one or more styluses are constantly entering and exiting the sensing zone of the sensor controller, the sensor controller may not be able to quickly acquire the capability information of each entering stylus to start communication with the stylus in a manner appropriate for the stylus's particular capability. This may lead to slow response time of the sensor controller and hence delay in establishing communication between the sensor controller and the active stylus. For example, the sensor controller may not be able to promptly receive pen orientation data from a stylus, even when the stylus is fully capable of transmitting such orientation data, simply because the sensor controller cannot quickly ascertain the stylus's orientation detection capability.

BRIEF SUMMARY

The present disclosure offers a technical solution that allows a sensor controller to quickly determine the capability information of one or more active styluses that enter the sensing zone to thereby start bidirectional communication with the styluses. The disclosure provides a universal stylus-sensor controller interface, which supports different active styluses having different capability information. The disclosure further provides a sensor controller-host processor interface, which supports different types of sensor controllers that may be coupled to the host processor and thus supports different types of active styluses used with various sensor controllers.

According to one aspect, a method is provided for communication between a host processor and an active stylus via a sensor controller, wherein the sensor controller is coupled to a sensor configured to interact with the active stylus. The method includes generally three steps. First, the host processor transmits a command received from an application operating on the host processor. Second, the sensor controller receives the command from the host processor and forwards the command to the active stylus. Third, the active stylus, in response to the command, operates on the command and transmits a command response to the sensor controller.

According to the method, the host processor or, more specifically an application operating on the host processor (e.g., drawing application), may transmit a command to the active stylus, for example, to inquire status of the active stylus or to configure (set) certain attributes for the active stylus.

According to one aspect, the sensor controller stores the command response returned from the active stylus in a memory device coupled to the sensor controller. The host processor may subsequently request to retrieve the command response from the memory device of the sensor controller.

According to one aspect, the sensor controller and the host processor are configured to be connected via a Universal Serial Bus (USB) interface, an Inter-Integrated Circuit (I2C) bus, or a Serial Peripheral Interface (SPI) bus.

According to one aspect, the command is a request command to the active stylus.

According to one aspect, the command is a request command to identify an attribute of the active stylus, such as the active stylus's preferred color value, preferred line width value, or preferred line style value.

According to another aspect, the command is a setting command to set an attribute for the active stylus, such as a preferred color value, a preferred line width value, or a preferred line style value.

According to one aspect, the command response from the active stylus includes data derived as a result of the operating on the command.

According to another aspect, a sensor controller is provided to be coupled to a sensor and to a host processor, wherein the sensor includes a matrix of electrodes to receive signals from and transmit signals to an active stylus. The sensor controller includes reception circuitry which, in operation, receives a command from an application operating on the host processor. The sensor controller also includes a memory device, and processing circuitry coupled to the reception circuitry and the memory device. The processing circuitry, in operation, forwards the received command, via the matrix of electrodes of the sensor, to the active stylus. The processing circuitry receives a command response, via the matrix of electrodes of the sensor, from the active stylus. The processing circuitry stores the received command response in the memory device.

According to a further aspect, a host processor is provided. The host processor includes transmission circuitry which, in operation, transmits a command from an application operating on the host processor to a sensor controller coupled to a sensor configured to interact with an active stylus. The host processor also includes processing circuitry coupled to the transmission circuitry. The processing circuitry is configured to request retrieval of a command response, which is returned from the active stylus in response to the command and stored in a memory device of the sensor controller. The host processor further includes reception circuitry which, in operation, receives the command response retrieved from the memory device of the sensor controller.

According to yet another aspect, a system is provided, which includes: (a) a host processor configured to transmit a command from an application operating on the host processor, (b) an active stylus configured to interact with a sensor, and (c) a sensor controller coupled to the sensor. The sensor controller (c) includes: sensor reception circuitry which, in operation, receives the command from the host processor; a memory device; and sensor processing circuitry coupled to the sensor reception circuitry and the memory device and configured to forward the received command to the active stylus. The active stylus, in response to the command, operates on the command and returns a command response to the sensor controller.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a diagram illustrating an overall system including an active stylus and an electronic device (e.g., tablet computer), wherein the electronic device includes a sensor, a sensor controller coupled to the sensor, and a host processor of the electronic device coupled to the sensor controller.

FIG. 2A is a functional block diagram of a sample active stylus.

FIG. 2B is a functional block diagram of a sample sensor controller.

FIG. 3 is a sample frame format for use in bidirectional communication between a stylus and a sensor controller, wherein the frame is divided into sixteen (16) time slots s0-s15.

FIG. 4A is a table listing sample types of stylus capability information of an active stylus, including capability information regarding predefined (preconfigured) capability of the active stylus and setting information regarding user-adjustable setting of the active stylus.

FIG. 4B is a table listing a sample data format for use by an active stylus to transmit capability information of the active stylus to the sensor controller.

FIG. 4C is a table listing sample orientation codes for use by an active stylus to transmit capability information regarding orientation detection capability of the active stylus.

FIG. 4D is another example of a table listing capability information, in particular, orientation detection capability of the active stylus.

FIG. 4E describes three examples of stylus capability information regarding predefined capability of an active stylus.

FIG. 5A is a table listing sample operational data indicative of an operational state of an active stylus, which is transmitted from the active stylus to the sensor controller according to a schedule set by a downlink time slot allocation.

FIG. 5B is a table showing a downlink data packet format for one type of operational data, i.e., IMU (inertial measurement unit) data.

FIG. 5C is a table listing sample operational data indicative of an operational state of an active stylus, which is transmitted to the sensor controller when polled (requested) by the sensor controller.

FIG. 6 is a flowchart illustrating a sample process flow of an active stylus.

FIG. 7 is a flowchart illustrating a sample flow of a sensor controller, in particular, of performing pairing operation with an active stylus, in which the sensor controller receives a hash value indicative of the stylus capability information (e.g., setting information) from the active stylus and determines whether it recognizes the received hashed value and, if so, speeds up the pairing operation.

FIGS. 8A and 8B illustrate sample frame formats, in which a sensor controller transmits a beacon signal (BS) to an active stylus, and the active stylus, in response, transmits a signal including stylus capability information (CP or Hash#1) back to the sensor controller.

FIGS. 9A-9G illustrate seven different frame formats, in which an active stylus transmits packets to the sensor controller according to six different kinds of downlink time slot allocation specified by the sensor controller, respectively.

FIG. 10 is a flowchart illustrating a sample pairing operation between an active stylus and a sensor controller, in which the active stylus transmits a hash value indicative of its capability information, and the sensor controller determines whether it recognizes the received hashed value and, if so, speeds up the pairing operation. The sensor controller additionally uses a second hash value as further verification that the received capability information is from the previously-paired stylus.

FIG. 11 is a diagram illustrating an overall system including an active stylus and an electronic device, wherein the electronic device includes a sensor, a sensor controller coupled to the sensor, and a host processor of the electronic device coupled to the sensor controller, particularly illustrating bidirectional communications between the sensor controller and the host processor.

FIG. 12A is a flowchart illustrating a method of communication between the sensor controller and the host processor based on a default descriptor that supports transmission of stylus reports including various sets of stylus attributes.

FIG. 12B is another flowchart illustrating a method of communication between the sensor controller and the host processor based on a default descriptor that supports transmission of stylus reports including various sets of stylus attributes.

FIG. 12C is a flowchart illustrating a method of communication between the host processor, which sends a command intended for the active stylus to the sensor controller, which forwards the command to the active stylus and receives and stores a command response returned from the active stylus for later retrieval by the host processor.

FIG. 13 is a sample default descriptor including a defined set of stylus attributes.

FIG. 14 is a table illustrating stylus attributes included in a full report supported by a first (full) description of the default descriptor, and in a short report supported by a second (partial) description of the default descriptor of FIG. 13.

FIG. 15 is a sample partial description, which is part of the default descriptor of FIG. 13, including a subset of the defined set of stylus attributes.

FIG. 16 is a sequence diagram of the method of FIG. 12C, illustrating interactive operation of the host processor, which sends a command to the sensor controller, which forwards the command to the active stylus, which then returns a command response.

DETAILED DESCRIPTION

FIG. 1 illustrates an overall system including an active stylus 100 and an electronic device (e.g., PC, tablet computer, smartphone) 3. The electronic device 3 includes a sensor 201, a sensor controller 200 coupled to the sensor 201, and a host processor 300 of the electronic device 3 coupled to the sensor controller 200. While FIG. 1 illustrates the sensor controller 200 and the host processor 300 as included in the electronic device 3, in various embodiments the host processor 300 may be independently provided to be coupled to the electronic device 3 (e.g., a tablet peripheral device) that contains the sensor controller 200.

The electronic device 3, such as a PC, tablet computer, smartphone, etc., typically includes a screen that underlies or overlies the sensor 201, and a user operates the active stylus 100 to handwrite text and graphics on the screen. As used herein, an active stylus is a stylus that contains electronics and a power source 105, such as a battery or a parasitic energy conduit. The sensor 201 may be any suitable stylus sensitive sensor known in the art, such as a capacitive touch/stylus sensor, resistive touch/stylus sensor, electromagnetic resonance stylus sensor, optical stylus sensor, ultrasonic stylus sensor, etc. Some are stylus sensors, while others are sensors capable of detecting both an active stylus and a finger touch. The sensor controller 200, which will be described in detail in reference to FIG. 2B below, controls operation of the sensor 201, performs bidirectional communication with the active stylus 100, and also communicates with the host processor 300. For example, the sensor controller 200 processes handwritten input data from the active stylus 100 to determine the (X,Y) coordinates and color of a position indicated (pointed to) by the active stylus 100 on the sensor 201, and forwards the (X,Y) coordinates and color information to the host processor 300 of the electronic device 3. The host processor 300 is typically a controller or CPU with memory, etc. The sensor controller 200 and the host processor 300 are connected via a suitable interface, such as the USB Human Interface Devices (HID) Protocol (PTCL). Communications between the active stylus 100 and the sensor controller 200 will be first described generally in reference to FIGS. 1-10, and thereafter communications between the host processor 300 and the sensor controller 200 (which in turn communicates with the active stylus 100) will be described generally in reference to FIGS. 11-16.

The active stylus 100, which will be described in detail in reference to FIG. 2A below, includes a stylus capability information manager 110 including memory/cache that stores stylus capability information of the stylus, for example, in the form of tables (TBL). As will be more fully described below, the stylus capability information may include capability information regarding predefined (e.g., manufacturer-configured) capability of the stylus, which is typically not changeable, and setting information regarding user-adjustable setting of the stylus. The stylus capability information manager 110 updates the setting information each time a user changes the stylus setting, such as the stylus color and stylus line width, using, for example, switches (buttons) 111 provided on the stylus 100. In FIG. 1, two such buttons are illustrated: one tail button 111A and one side button 111B. The active stylus 100 also includes a data manager 112, which prepares operational data indicative of operational state of the active stylus, such as stylus (pen) tip pressure data and stylus orientation data (e.g., how much the stylus is twisted or tilted relative to the sensor surface).

The stylus capability information manager 110 and the data manager 112 are both coupled to a communication module 130 including transmission (TX) and reception (RX) circuitry. The communication module 130 transmits the stylus capability information and operational data of the active stylus 100 to the sensor controller 200, and receives various commands and other information (in beacon signals) from the sensor controller 200, as will be more fully described below. In this bidirectional communication protocol, the sensor controller 200 is a master device and the active stylus 100 is a slave device. In the present disclosure, the transmission direction from the sensor controller 200 to the active stylus 100 is called “uplink” and the transmission direction from the active stylus 100 to the sensor controller 200 is called “downlink.”

As schematically illustrated in FIG. 1, a typical bidirectional communication flow between the active stylus 100 and the sensor controller 200 starts with the active stylus 100 entering the sensing zone (SZ) of the sensor controller 200 during pen-down operation indicated by a down arrow. Once the active stylus 100 is inside the sensing zone, it can detect beacon signals periodically transmitted from the sensor controller 200 via the sensor 201. Upon detecting the beacon signal, the active stylus 100 transmits a response signal, which includes the stylus capability information retrieved from the stylus capability information manager 110. As will be described in detail in reference to FIG. 10 below, the setting information of the active stylus 100 may be hashed to generate a hash value of fixed (smaller) size (“Hash#1”), which can be advantageously transmitted in one time slot to the sensor controller 200. Hash#1 has a corresponding hash value of fixed size (“Hash#2”). If the active stylus 100 has previously been paired with the sensor controller 200, then both the active stylus 100 and the sensor controller 200 have Hash#1 and Hash#2, which are calculated from the particular setting information of the active stylus 100 when it was paired with the sensor controller 200. Therefore, if the sensor controller 200 recognizes the received Hash#1, the sensor controller 200 knows that it was previously paired with the active stylus 100 and, thus, is already aware of the stylus capability information of the active stylus 100 including the particular setting information. The sensor controller 200 can then use the same downlink time slot allocation as previously assigned to the active stylus 100 to start bidirectional communication with the active stylus 100. In addition the sensor controller 200 may return Hash#2, which corresponds to the received Hash#1, to the active stylus 100 to verify that it has correctly recognized the active stylus 100. As will be more fully described below, use of Hash#1 speeds up the pairing process between the active stylus 100 and the sensor controller 200 each time the active stylus 100 reenters the sensing zone of the sensor controller 200, which is a particularly advantageous technical feature when the active stylus 100 repeatedly exits (see “Pen up” arrow) and reenters (see “Pen down” arrow) the sensing zone.

As used herein, “pairing” operation refers to a process that starts with transmission of a response signal from the active stylus 100, which has detected an initial (discovery) beacon signal from the sensor controller 200, and ends with transmission of another beacon signal including a downlink time slot allocation for the active stylus 100 from the sensor controller 200. The sensor controller 200 determines a downlink time slot allocation for a given active stylus in view of the stylus capability information of the active stylus, to thereby establish a unique communication link, fully supportive of the stylus capability, with the active stylus. Thus, at the conclusion of pairing operation, the active stylus may start bidirectional communication with the sensor controller using the newly established unique communication link.

Use of Hash#1 is also advantageous in achieving “fast inking.” Before an application program can start to draw, it needs to know the parameters for the line it is about to render on a screen. These parameters include, for example, the color or the brush style (airbrush, chalk, etc.) of the line. Use of Hash#1 allows a sensor controller to quickly recognize that it already has these parameters cached for a particular stylus that has entered the sensing zone, and to make these parameters available to the application program to start drawing, or “inking,” almost immediately.

FIG. 2A is a functional block diagram of a sample active stylus 100. The active stylus 100 includes a TX/RX electrode 115 at its tip, switch SW coupled to the TX/RX electrode 115, reception circuitry 117, transmission circuitry 119, and a micro-controller unit (MCU) 120. The MCU 120 is a microprocessor including internal ROM and RAM and configured to operate according to a defined program. Switch SW couples the TX/RX electrode 115 to either a reception terminal R or a transmission terminal T as directed by switch control signal SWC from the MCU 120. Initially switch SW connects the TX/RX electrode 115 to the reception terminal R while the active stylus 100 listens for beacon signals from the sensor controller 200. The reception circuitry 117 includes electronic components necessary to receive and process signals from the TX/RX electrode 115 and output them in digital form usable by the MCU 120. When the MCU 120 detects a beacon signal from the sensor controller 200, it prepares a response signal (e.g., an ACK signal) in cooperation with the transmission circuitry 119, and also sends switch control signal SWC to switch SW to connect the TX/RX electrode 115 to the transmission terminal T to transmit the response signal via the TX/RX electrode 115 to the sensor controller 200.

The transmission circuitry 119 includes electronic components necessary to receive and process signals from the MCU 120 and output them to be transmitted via the TX/RX electrode 115 to the sensor controller 200. For example, the transmission circuitry 119 generates a carrier signal at a frequency specified by the MCU 120 and may output the carrier signal, without modulation, as “position packets” to be used by the sensor controller 200 to determine (calculate) a position indicated by the active stylus 100. Alternatively, the transmission circuitry 119 may modulate the carrier signal with the stylus capability information of the active stylus 100, such as Hash#1 indicative of the setting information, using any suitable modulation schemes such as PSK (phase shift keying), D-BPSK (differential binary PSK), QAM (quadrature amplitude modulation) and DSSS (direct sequence spread spectrum). Then the signal modulated with the stylus capability information is transmitted via the TX/RX electrode 115 to the sensor controller 200.

The transmission circuitry 119 may modulate the carrier signal with information other than the stylus capability information, such as operational data indicative of operational state of the active stylus 100. Operational data may include, for example, stylus (pen) tip pressure data, stylus barrel pressure data, stylus orientation (e.g., twist/tilt) data, stylus switch status, and stylus battery level. To generate such operational data, the active stylus 100 includes one or more sensors 122, such as a stylus (pen) tip pressure sensor 122 a (e.g., comprised of a variable capacitor) configured to sense pressure applied to the stylus tip, barrel pressure sensor configured to sense pressure applied to the stylus barrel, 9-axis or lesser-axis IMU (inertial measurement unit) 122 b (consisting of one or more combinations of 3-axis gyroscopes, 3-axis accelerometers, and 3-axis magnetometers), twist sensor 122 c configured to sense twist/rotation of the active stylus 100 about its axis relative to the direction of each of X electrodes (or Y electrodes) of the sensor 201, tilt sensor 122 d configured to sense X- and Y-directional tilt of an axis of the active stylus 100 relative to the surface of the sensor 201, etc. (Illustration of the sensors 122 b-122 d other than the stylus tip pressure sensor 122 a is omitted). The MCU 120 and the transmission circuitry 119 prepare outputs from these sensors into “data packets” to be transmitted via the TX/RX electrode 115 to the sensor controller 200. To transmit the data packets to the sensor controller 200, the MCU 120 sends switch control signal SWC to switch SW to connect the TX/RX electrode 115 to the transmission terminal T.

Different active styluses have different sensing capabilities; some styluses are fully equipped with various sensors, while other styluses include only the stylus tip pressure sensor 122 a. As will be more fully described below, the present invention proposes a bidirectional communication protocol that permits the sensor controller 200 to quickly ascertain the particular capability of a given active stylus entering the sensing zone, to thereby configure a unique communication link (based on a specific downlink time slot allocation) that is supportive of the stylus's capability.

FIG. 2B is a functional block diagram of a sample sensor controller 200. The sensor controller 200 is part of the electronic device 3 (see FIG. 1) and is coupled to the sensor 201 including a matrix of X electrodes 201X and Y electrodes 201Y, on which the active stylus 100 carries out various handwriting operation. The sensor controller 200 is also coupled to the host processor 300 of the electronic device 3.

The sensor controller 200 includes transmission circuitry 210, a selector 220, reception circuitry 230, a logic unit 235, and an MCU (micro-controller unit) 240. The MCU 240 is a microprocessor including internal ROM and RAM and configured to operate according to a defined program. The MCU 240 directs the logic unit 235 to issue control signaling (ctr, sTRx, sTRy, selX, selY, etc.) to control operation of the transmission circuitry 210, selector 220 and reception circuitry 230. The MCU 240 processes digital data received from the reception circuitry 230 to determine/calculate the X- and Y-coordinates, color, opacity (darkness), etc., of a point indicated by the active stylus 100 on the sensor 201, and outputs the calculated point data to the host processor 300 of the electronic device 3 for display, for example.

The transmission circuitry 210 includes electronic components necessary to receive and process signals from the MCU 240 and output them to be transmitted via the matrix electrodes of the sensor 201 to the active stylus 100. Specifically, under the control of the MCU 240, the transmission circuitry 210 generates periodic beacon signals to be transmitted via the matrix electrodes of the sensor 201 to the active stylus 100. As will be more fully described below, beacon signals are used (detected) by nearby active styluses to discover the sensor controller 200 and serve as timing reference by the active styluses to synchronize with the sensor controller 200. Additionally, a beacon signal may include Hash#2, which the sensor controller 200 that has received Hash#1 from the active stylus 100 may transmit back to the active stylus 100 for verification, as described above. Beacon signals may include a downlink time slot allocation determined for the active stylus, to thereby notify the active stylus what downlink time slots to use to transmit what types of packets to the sensor controller. Further additionally, beacon signals may include various commands to control operation of the active stylus 100. For example, beacon signals may include a read command to request the active stylus 100 to transmit (additional) stylus capability information to the sensor controller 200, or a write command to configure (write in) capability information for the active stylus 100. Beacon signals may also include a polling command to request (poll) the active stylus to transmit operational data of the active stylus, such as a battery level of the active stylus, to the sensor controller. The transmission circuitry 210 may modulate a carrier signal that forms a beacon signal with Hash#2, with the downlink time slot allocation or with these various commands received from the MCU 240, using any suitable modulation schemes such as PSK, D-BPSK, QAM and DSSS.

The reception circuitry 230 includes electronic components necessary to process signals received from the active stylus 100 via the matrix electrodes of the sensor 201 and output them in digital form usable by the MCU 240. For example, the reception circuitry 230 processes and outputs response signals (in response to the beacon signals), data packets (including operational data of the active stylus) and position packets received from the active stylus 100 to the MCU 240. When the sensor 201 is capable of detecting a finger touch as well as the active stylus 100, the reception circuitry 230 receives via the matrix electrodes of the sensor 201 signals indicative of a finger touch as well as signals transmitted from the active stylus 100, and processes and outputs them to the MCU 240, which determines a finger touch position as well as a position indicated by the active stylus 100.

The selector 220, based on control signaling from the logic unit 235, switches operational modes of the sensor 201 between transmission mode and reception mode. The selector 220 includes switches 222 x and 222 y, and electrode selection circuitry 224 x and 224 y. Based on control signaling sTRy and sTRx from the logic unit 235, the switches 222 x, 222 y connect the X-electrodes 201X and Y-electrodes 201Y of the sensor 201, respectively, to either a transmission terminal T coupled to the transmission circuitry 210 or a reception terminal R coupled to the reception circuitry 230. The electrodes coupled to the transmission circuitry 210 are used in transmission mode to transmit signals to the active stylus 100, and the electrodes coupled to the reception circuitry 230 are used in reception mode to receive signals from the active stylus 100. Further, based on control signaling selX and selX, the electrode selection circuitry 224 x and 224 y select X-electrodes 201X and Y-electrodes 201Y, respectively, to transmit or receive signals to or from the active stylus 100. The logic unit 235 additionally sends control signaling “ctr” to the transmission circuitry 210 and the reception circuitry 230 to control their operation as directed by the MCU 240.

FIG. 3 is a sample frame format for use in bidirectional communication between an active stylus 100 and a sensor controller 200, wherein the bidirectional communication resource is divided into frames along a time axis and is divided into different frequencies along a frequency axis. Each frame is further divided into sixteen (16) time slots s0-s15 along the time axis, wherein each time slot is sized to accommodate up to 20 bits (16 information bits plus 4 CRC bits) for example. In one example, a frame length is 16 msec and a time slot length is 1 msec. It should be noted that a frame may be divided into less or more than 16 time slots, and the invention is not limited to the 16-time slot example illustrated herein. For example, a 16-msec frame may be divided into 64 time slots, wherein each time slot is 250 μsec long.

In exemplary embodiments, one or more time slots at the beginning of each frame are used in “uplink” by the sensor controller 200 to send periodic beacon signals (BS) to the active stylus 100. Thus, a frame may be considered as an interval between the beginnings of two successive beacon signals. Other time slots in each frame are used in “downlink” by the active stylus 100 to send signals (e.g., response signals to the beacon signals), data packets and position packets to the sensor controller 200, as illustrated in various examples of FIGS. 8A-9G to be described below. Though not illustrated, a gap time slot may be provided between the uplink time slot (s0 in FIG. 3) and the downlink time slots (s1-s15 in FIG. 3), during which no transmission is scheduled, uplink or downlink, to avoid collision between uplink transmission and downlink transmission.

Beacon signal is a periodic signal sent by the sensor controller 200 to allow nearby active styluses to discover the sensor controller 200 and to serve as timing reference for time slots used in bidirectional communication between the sensor controller 200 and the active styluses 100. Thus, in a typical embodiment, beacon signals are transmitted at all frequencies to be detectable by all active styluses. Each active stylus 100 listens for beacon signals and, after it detects a beacon signal, it sets its timing reference based on the beacon signal. Beacon signals subsequent to the initial beacon signal detected by the active stylus 100 to discover the sensor controller 200 may include various information, such as Hash#2 used to verify that the active stylus 100 was previously paired with the sensor controller 200, and commands to control operation of the active stylus 100 during and after the pairing operation. A beacon signal including Hash#2 or commands directed to the active stylus 100 typically includes a stylus ID of the active stylus 100 such that the active stylus 100 can identify which beacon signals are directed to the active stylus 100 (as opposed to other active styluses, if any). Beacon signals from the sensor controller 200 also typically include a sensor controller ID of the sensor controller 200.

In accordance with various embodiments, the sensor controller 200 quickly ascertains capability information of each active stylus 100 that is entering the sensing zone of the sensor controller 200 and determines, based on the ascertained capability information, a downlink time slot allocation for the active stylus 100. The active stylus 100 then starts bidirectional communication with the sensor controller, by transmitting data packets and/or position packets to the sensor controller according to the determined downlink time slot allocation that is supportive of the capability of the active stylus 100. For example, when the sensor controller 200 determines that a given active stylus has stylus orientation detection capability, the sensor controller 200 assigns downlink time slots for the active stylus 100 to transmit stylus orientation data to the sensor controller 200, while the sensor controller 200 does not assign such downlink time slots to an active stylus that does not have stylus orientation detection capability. Thus, the sensor controller 200 may assign a different downlink time slot allocation to an active stylus depending on the capability information of the active stylus. Because setting information regarding user-adjustable setting of the active stylus (e.g., stylus line width) may be modified while the active stylus is outside the sensing zone of the sensor controller 200, the sensor controller needs to ascertain the current setting information each time the active stylus reenters the sensing zone even when the active stylus has been previously paired with the sensor controller.

FIG. 4A is a table listing sample types of stylus capability information of an active stylus, including capability information and setting information. Capability information relates to predefined capability of the active stylus that is preconfigured, typically by a stylus vendor (manufacturer), and is typically not user-changeable. For example, the number of barrel switches provided on a stylus is not user-changeable. Capability information may also include a version number (4 bits) indicative of which version of the bidirectional communication protocol the active stylus complies with. Capability information may still further include “preferred color” (8 bits to indicate one of 140 CSS (Cascading Style Sheet) colors), which is a preferred or default color of the active stylus to be displayed on a screen of the sensor 201. Capability information may also relate to various other capabilities that may be configured for the active stylus by a vendor, as will be more fully described below in reference to FIG. 4B.

FIG. 4A also describes some setting information regarding user-adjustable setting of the active stylus, such as a “pen style” including a stylus line width and a stylus tip type (e.g., 0=pen, 1=eraser, 2=chisel tip marker, 3=airbrush, 4=pencil, and 5-7=reserved for custom/vendor-specific tip styles) and functions assigned to the tail/barrel buttons (switches) 111A/111B of the active stylus. For example, a user may change the pen style by operating the buttons (switches), or change the functions assigned to the buttons (switches). Setting information may relate to other user-changeable setting that may be configured for the active stylus. A unique identifying number of the active stylus may be changeable by a user through one or more switches located on the active stylus. For example, a vendor ID (8 bits) and a serial number (56 bits), which together form a 64-bit global ID for each stylus, can be user-changeable. (In some embodiments, a global ID is not user-changeable.) Also, the “preferred color” of the active stylus, which is described above as one type of capability information, may instead be user-adjustable setting information and a user may freely adjust the preferred (default) color using the buttons (switches) for example. As the example of “preferred color” indicates, difference between capability information and setting information is not rigid, and may change from vendor to vendor, or from stylus to stylus. Also, there may be some setting information that may be set by a user only once, or very infrequently, such that it may be treated as capability information.

FIG. 4B is a table listing a sample data format for use by an active stylus to transmit its capability information to the sensor controller 200. Capability information includes, for example, information regarding how many different levels (e.g., 256, 512, 1024, etc.) the pen tip pressure can be detected; the number of barrel buttons (e.g., 111A/111B) provided on the active stylus; the stylus's capability to detect barrel pressure (no or yes, and if yes, how many different levels the barrel pressure can be detected); and the stylus's capability to detect stylus orientation (e.g., stylus twist and tilt) as will be more fully described below in reference to FIG. 4C.

Capability information of FIG. 4B may further include information regarding whether a custom (customized) data size is set for a data packet (no or yes) and, if yes, the number of custom data bytes; the orientation resolution in which the stylus's orientation can be detected (e.g., 0 indicates 8 bit resolution, 1 indicates 9 bit resolution, and 2 indicates 10 bit resolution); the customized number (as opposed to default numbers) of different levels at which the pen tip pressure can be detected; the customized number (as opposed to default numbers) of barrel buttons provided on the active stylus; and the customized number of data bytes used to transmit orientation data (as opposed to default data bytes).

FIG. 4C is a table listing sample orientation codes for use by an active stylus to transmit capability information regarding the stylus's orientation detection capability to the sensor controller. An orientation code of 0 indicates the active stylus has no orientation detection capability; 1 indicates the active stylus can detect tilt in both X-direction and Y-direction and the detected X- and Y-tilt data can be transmitted in 2 time slots per frame; 2 indicates the active stylus can detect and transmit X- and Y-tilt plus twist (rotation) data in 3 time slots per frame; 3 indicates the active stylus can detect and transmit altitude and azimuth data of the active stylus relative to the sensor surface in 2 time slots per frame; 4 indicates the active stylus can detect and transmit altitude and azimuth data as well as twist (rotation) data in 3 time slots per frame; 5 indicates the active stylus includes a 6-axis IMU (inertial measurement unit) consisting of a combination of 3-axis gyroscope and 3-axis accelerometer and can transmit 6-axis IMU data in 3 time slots per frame; 6 indicates the active stylus includes a 9-axis IMU consisting of a combination of 3-axis gyroscope, 3-axis accelerometers and 3-axis magnetometer, and can transmit 9-axis IMU data in 3 time slots per frame, and 7 indicates a customized form of orientation data that can be detected and transmitted by the active stylus.

While the orientation code table of FIG. 4C shows different values 0 to 7 for different types of orientation sensors, an alternative approach is to provide a bit field of capabilities, as shown in FIG. 4D, which the active stylus can use to notify its orientation capability to the sensor controller. Each of the bits that are set in the capability information indicates that the stylus is capable of measuring that item. If the Barrel pressure bit is set in the capability information field, it indicates the stylus has a barrel pressure indication. If the Tilt bit is set it indicates the stylus is capable of measuring X and Y tilt. If the Twist bit is set it indicates the stylus is capable of measuring stylus axial twist. If the Altitude & Azimuth bit is set it indicates the stylus is capable of measuring altitude and azimuth of the stylus. If the IMUhasAccel bit is set it indicates the stylus has a three-axis accelerometer. If the IMUhasGyro flag is set it indicates the stylus has a three-axis gyroscope. If the IMUhasMagnet bit is set it indicates the stylus has a three-axis magnetometer.

Each of these bits that are set indicates the need to allocate a time slot for that data, although as will be described below, for an IMU it is possible to multiplex data into a single time slot or a set of time slots.

FIG. 4E describes three examples of capability information of an active stylus. Example 1 is the capability information of a first active stylus, which can detect stylus tip pressure at 1024 different levels, has 1 barrel button, has no tangential (barrel) pressure sensing capability, no stylus orientation sensing capability and no custom capability. Example 2 is the capability information of a second active stylus, which can detect stylus tip pressure at 2048 different levels, has 2 barrel buttons, has tangential (barrel) pressure sensing capability, has stylus orientation sensing capability based on a 9-axis IMU (Orientation Code 6 in FIG. 4C), and has no custom capability. Example 3 is the capability information of a third active stylus, which can detect stylus tip pressure at a customized number of different levels wherein each pressure level (value) is expressed in 16 bits, has no barrel buttons and no tangential (barrel) pressure sensing capability, and has stylus orientation sensing capability to detect and report altitude and azimuth data as well as twist (rotation) data of the active stylus (Orientation Code 4 in FIG. 4C).

FIG. 5A is a table listing sample operational data indicative of the operational state of an active stylus, which may be transmitted from the active stylus to the sensor controller according to a schedule set by a downlink time slot allocation for the active stylus. In various embodiments, operational data transmitted according to a schedule are operational data the sensor controller needs to achieve proper interactive operation between the sensor controller and the active stylus. Such operational data include, for example, tip pressure data, tangential (barrel) pressure data, status of each barrel button (e.g., on/off state of each barrel button), invert data indicative of whether the active stylus is inverted from its intended orientation (i.e., the stylus tip is pointed upwardly, meaning that the stylus tail is pointing to and is in contact with the sensor surface to be used as an “eraser,” for example), stylus orientation data, and any other customized operational data indicative of some operational state of the active stylus.

In some cases the amount of operational data from sensors in the stylus may be large. This is especially true of IMUs. These sensors may have any or all of the following: accelerometers with one to three axes, gyroscopes with one to three axis, and magnetometers with one to three axes. This could result in the need to send up to nine axes of data. As an alternative to sending this data in nine time slots of a dedicated type (e.g., X, Y, Z axes of the accelerometer; X, Y, Z axes of the gyroscope; and X, Y, Z axes of the magnetometer), the data can be multiplexed into one or more time slots.

To accomplish the multiplexing, the IMU data is tagged with a flag (IMU flag) to indicate which sensor (accelerometer, gyroscope, or magnetometer) the data came from. FIG. 5B, is an example of a data packet (or a report) for transmitting IMU data. In FIG. 5B, the “IMU data” field includes the IMU data itself, and the “IMU Flag” field indicates which sensor produced the IMU data. For example, if the IMU Flag is zero it could indicate that the data came from an accelerometer, if the IMU Flag is one it could indicate that the data came from a gyroscope, and if the IMU Flag is two it could indicate the data came from a magnetometer. The IMU data field may include X, Y, Z axes data produced by the sensor indicated by the IMU Flag.

For example, the nine axes of data (e.g., X, Y, Z axes of the accelerometer; X, Y, Z axes of the gyroscope; and X, Y, Z axes of the magnetometer) can be multiplexed into three time slots (or three data fields) of a common report format (or data packet), to form three reports at three different times, as below:

(report 1)

Sensor tag—“Accelerometer”

X axis data field—Accelerometer X axis data

Y axis data field—Accelerometer Y axis data

Z axis data field—Accelerometer Z axis data

(report 2)

Sensor tag—“Gyroscope”

X axis data field—Gyroscope X axis data

Y axis data field—Gyroscope Y axis data

Z axis data field—Gyroscope Z axis data

(report 3)

Sensor tag—“Magnetometer”

X axis data field—Magnetometer X axis data

Y axis data field—Magnetometer Y axis data

Z axis data field—Magnetometer Z axis data

As another example, the nine axes of data can be multiplexed into one time slot (or one data field) of a common report format, to form nine reports at nine different times:

(report 1)

Sensor tag—“Accelerometer”

Axis tag—“X”

Data field—Accelerometer X axis data

(report 2)

Sensor tag—“Accelerometer”

Axis tag—“Y”

Data field—Accelerometer Y axis data

(report 3)

Sensor tag—“Accelerometer”

Axis tag—“Z”

Data field—Accelerometer Z axis data

(report 4)

Sensor tag—“Gyroscope”

Axis tag—“X”

Data field—Gyroscope X axis data

(report 5)

Sensor tag—“Gyroscope”

Axis tag—“Y”

Data field—Gyroscope Y axis data

(report 6)

Sensor tag—“Gyroscope”

Axis tag—“Z”

Data field—Gyroscope Z axis data

(report 7)

Sensor tag—“Magnetometer”

Axis tag—“X”

Data field—Magnetometer X axis data

(report 8)

Sensor tag—“Magnetometer”

Axis tag—“Y”

Data field—Magnetometer Y axis data

(report 9)

Sensor tag—“Magnetometer”

Axis tag—“Z”

Data field—Magnetometer Z axis data

Multiplexing the IMU data into one or more time slots (one or more data fields) in this manner has the advantage of reducing the number of required time slots in each report, at the expense of increasing the number of reports needed to transmit the IMU data, slowing down the overall IMU data rate.

In some embodiments the data from multiple IMU sensors may be combined in a process known as “sensor fusion” to produce desired position and motion information. For example, when it is desired to determine which direction of the active stylus is “down,” the gyroscope data that indicates the direction of movement may be subtracted from the accelerometer data that indicates both the acceleration direction of movement and the acceleration direction of gravity. The result of the subtraction indicates the acceleration direction due to gravity alone, i.e., the “down” frame of reference.

In performing “sensor fusion,” the data from various IMU sensors should be measured as close in time as possible relative to each other to give the most accurate results. The “End” bit shown in FIG. 5B may be used to achieve synchronization among the data from various IMU sensors as follows. A measurement of the multiple IMU sensors is taken and buffered in the active stylus. This buffered data is sent in the available IMU time slot allocations with the End bit clear (e.g., “0”). FIG. 9G shows an example of IMU data packet and a usage of ‘End bit.’ When the last buffered data element is placed in a time slot the End bit is set (e.g., to “1”) to indicate it is the last in the set of IMU data obtained by the multiple IMU sensors simultaneously or close in time. In the sensor controller, any IMU data received with the End bit clear is added to a buffer. When the sensor controller receives IMU data with the End bit set, the sensor controller may then use the data in the buffer as a complete set of IMU data from the multiple IMU sensors, for transfer to the host processor to perform sensor fusion.

FIG. 5C is a table listing sample operational data indicative of operational state of an active stylus, which the active stylus transmits to the sensor controller when polled (requested) by the sensor controller, such as a battery level of the active stylus. Thus, this type of operational data is only infrequently transmitted to the sensor controller.

It should be noted that the stylus capability information described above in reference to FIGS. 4A-4E and the operational data described above in reference to FIGS. 5A-5C are examples only, and the present invention is not limited to using the particular examples disclosed in FIGS. 4A-5C.

FIG. 6 is a flowchart illustrating a sample process flow of an active stylus. In step S601, the active stylus determines its own stylus capability information, as stored in the table TBL of the stylus capability information manager 110 (FIG. 1) for example. When, in step S603, the active stylus detects user operation to modify the setting of the active stylus (e.g., stylus line width, color, etc.), in step S605 the active stylus updates the setting information accordingly. As shown in FIG. 6, steps S601-S605 typically occur while the active stylus 100 is outside the sensing zone of the sensor controller 200. In step S611, the active stylus listens for beacon signals from the sensor controller 200 and, if no beacon signal is detected, returns to step S603 and continues updating the setting information, as needed, and listening for beacon signals.

In step S611, upon entering the sensing zone of the sensor controller 200, the active stylus detects a beacon signal from the sensor controller 200. In step S613, the active stylus synchronizes its frame/time slots configuration with that of the sensor controller using the detected beacon signal as timing reference. In step S615, the active stylus sends a hashed value of the setting information (Hash#1) using a single downlink time slot to let the sensor controller determine whether the sensor controller recognizes the active stylus as the one the sensor controller has been previously paired with. If the sensor controller does not recognize the active stylus based on Hash#1, in step S617, in response to a capability information request (read) command received from the sensor controller, the active stylus sends its (complete) stylus capability information to the sensor controller, possibly using multiple downlink time slots. On the other hand, if the sensor controller recognizes the active stylus based on Hash#1, in step S619, the sensor controller sends a hashed value of the setting information (“Hash#2”) to the active stylus for verification, preferably using a single uplink time slot. Pairing and “fast inking” operation between the active stylus and the sensor controller using Hash#1 and Hash#2 will be described further in reference to FIGS. 7 and 10 below.

After sending non-hashed stylus capability information in step S617, or receiving Hash#2 of the setting information in step S619, in step S631 the active stylus again listens for beacon signals from the sensor controller 200. The beacon signal detected at this time includes a downlink time slot allocation, which the sensor controller has determined for the active stylus based on the stylus capability information of the active stylus. When the beacon signal including the downlink time slot allocation is detected, in step S633 the active stylus resets a counter to 0, and in step S635 starts to transmit packets to the sensor controller according to a schedule set by the downlink time slot allocation included in the detected beacon signal. The packets to be transmitted may be position packets to be used by the sensor controller to determine a position of the active stylus and/or data packets that include operational data (e.g., sensed pressure data, sensed orientation data, etc.) of the active stylus. Also, when polled (requested) by the sensor controller in the beacon signal detected in step S631 or in any subsequently detected beacon signal (not shown in FIG. 6), in step S637 the active stylus transmits a data packet including the polled operational data, such as a battery level of the active stylus, to the sensor controller according to the downlink time slot allocation. For example, the active stylus may use any time slot, which is not used to transmit the scheduled packets in step S635 above, to transmit the data packet including the polled operational data.

After transmitting the non-hashed stylus capability information in step S617 or receiving Hash#2 of the setting information in step S619, if the active stylus does not detect a beacon signal in return in step S631, in step S641 the active stylus determines whether the counter has exceeded a threshold value and, if not, increments the counter value in step S643. If the counter exceeds the threshold value in step S641, it is assumed that the active stylus has exited the sensing zone of the sensor controller 200 (i.e., the user has moved the active stylus away from the sensor 201) and is beyond the reach of beacon signals from the sensor controller. Thus, the active stylus returns to steps S603, S605 and S611, to resume updating the setting information, as needed, and listening for (initial) beacon signals.

FIG. 7 is a flowchart illustrating a sample process flow of a sensor controller. FIG. 7 also illustrates a sample pairing operation between the sensor controller and an active stylus, in which the sensor controller receives from the active stylus a hash value (“Hash#1”) indicative of the stylus capability information (e.g., setting information). If the sensor controller recognizes the received Hash#1, it may speed up the pairing operation.

In step S711, the sensor controller sends a beacon signal in the beginning time slot(s) of each frame, such as in the first time slot “s0.” In step S714, the sensor controller extracts a hashed value (Hash#1) of the stylus capability information from a response (e.g., ACK) signal returned from an active stylus, which has detected the beacon signal. Hash#1 may be the hashed value of the stylus capability information in complete form including both the capability information and the setting information, or may be of the setting information.

In step S715, the sensor controller determines whether the extracted Hash#1 corresponds to the hashed value (Hash#1) of the stylus capability information (e.g., setting information) cached in the sensor controller. Essentially, step S715 is a step in which the sensor controller determines whether it recognizes the active stylus as the one that the sensor controller has been previously paired with; if so the sensor controller already has complete stylus capability information of the active stylus.

If the sensor controller does not recognize Hash#1 in step S715, in step S717, the sensor controller sends a beacon signal including a read command to request the active stylus to transmit its stylus capability information. Alternatively or additionally the sensor controller may send a beacon signal including a write command to forcibly configure (set) a certain setting for the active stylus. For example, the sensor controller may issue a write command to set a certain default color for the active stylus.

In step S719, the sensor controller confirms that it has the stylus capability information of the active stylus, which the sensor controller has received in complete form using multiple downlink time slots (see step S617 in FIG. 6) or has confirmed as already cached in the sensor controller based on Hash#1. The sensor controller then determines a downlink time slot allocation for the active stylus based on the stylus capability information. The downlink time slot allocation specifies which downlink time slots in a frame are allocated to the active stylus and may also specify what types of packets (e.g., data packets or position packets) the active stylus should transmit in what downlink time slots. The sensor controller determines a downlink time slot allocation for each active stylus based on the particular capability information of the active stylus. For example, to an active stylus including stylus orientation and barrel pressure sensors in addition to a stylus tip pressure sensor, the sensor controller may allocate more downlink time slots to transmit operational data indicative of outputs from these various sensors, as compared to an active stylus that includes only a stylus tip pressure sensor. When multiple active styluses of various capabilities and settings are used with the sensor controller, the sensor controller determines a downlink time slot allocation for each active stylus while avoiding downlink time slot collision among the multiple active styluses. That is, in some embodiments, each time slot is allotted to one active stylus and is not shared by multiple styluses. In other embodiments, the sensor controller assigns a specific frequency to each active stylus as part of the downlink time slot allocation for the active stylus. Then, the same time slot may be assigned to multiple active styluses which are assigned multiple frequencies, respectively. Various examples of downlink time slot allocation will be described below in reference to FIGS. 8A-9G.

Referring back to FIG. 7, in step S731, the sensor controller sends a beacon signal including the determined downlink time slot allocation back to the active stylus that has sent the ACK signal. Then, in step S732 the sensor controller listens for packets to be transmitted from the active stylus according to the downlink time slot allocation. If the sensor controller detects packets from the active stylus, in step S733 the sensor controller resets a counter to 0, and in step S735 the sensor controller continues to receive packets (position packets and/or data packets including operational data) according to a schedule set by the downlink time slot allocation. Also, when the sensor controller polls the active stylus, in any of the beacon signals, to report certain operational data such as a battery level of the active stylus, in step S737 the sensor controller receives a data packet including the polled operational data from the active stylus.

After transmitting the beacon signal including the downlink time slot allocation in step S731, if the sensor controller does not detect any packets returned in the allocated downlink time slots in step S732, in step S741 the sensor controller determines whether the counter has exceeded a threshold value and, if not, increments the counter value in step S743. If the counter exceeds the threshold value in step S741, it is assumed that the active stylus has exited the sensing zone of the sensor controller 200 (i.e., the user has moved the active stylus away from the sensor 201) and is beyond the reach of beacon signals from the sensor controller. Thus, the sensor controller returns to steps S711 and S713 and continues to transmit periodic beacon signals and wait for a response signal from an active stylus.

FIGS. 8A and 8B illustrate sample frame formats, in which a sensor controller transmits a beacon signal (BS) to an active stylus, and the active stylus transmits a response signal including stylus capability information (CP or Hash#1) back to the sensor controller. In FIG. 8A, in time slot s0 of the first frame Fn, the sensor controller sends a beacon signal, and in the next time slot s1, an active stylus that has detected the beacon signal returns a response signal including non-hashed stylus capability information of the active stylus (“CP 1”). In this example, the active stylus has not been previously paired with and thus does not recognize the sensor controller (NO in step S615 of FIG. 6). Thus, the active stylus sends complete (non-hashed) stylus capability information in time slot s1, perhaps over multiple frames depending on the size of the complete stylus capability information. FIG. 8A shows that the active stylus transmits the non-hashed stylus capability information in time slot s1 of at least two frames, Fn and Fn+1, as CP1 and CP2.

In FIG. 8B, the active stylus has been previously paired with and thus recognizes the sensor controller (YES in step S615 of FIG. 6). Thus, the active stylus sends a hashed value of its setting information (“Hash#1”) in a response signal transmitted in time slot s1. Advantageously the hash value of the setting information is of fixed data size, which is typically 20 bits or less and can be transmitted in a single time slot. Therefore, unlike the example of FIG. 8A described above, Hash#1 representative of the setting information of the active stylus can be rapidly transmitted to the sensor controller using time slot s1 of a single frame (Fn).

The sensor controller, upon receiving and recognizing Hash#1 (YES in step S715 of FIG. 7), realizes that it already has the stylus capability information of the active stylus and, hence, the downlink time slot allocation for the active stylus. Thus, in time slot s0 of the next frame Fn+1, the sensor controller sends a beacon signal, which includes the downlink time slot allocation to be used by the active stylus to transmit packets to the sensor controller.

The sensor controller may notify the active stylus of the downlink time slot allocation in various ways. For example, upon recognizing Hash#1 transmitted from the active stylus, the sensor controller may send Hash#2 which corresponds to Hash#1 back to the active stylus. When the active stylus confirms that Hash#2 transmitted from the sensor controller corresponds to Hash#2 stored in the active stylus (wherein Hash#2 and Hash#1 are calculated based on the same setting information), the active stylus determines that it can use the same downlink time slot allocation that it used when it was previously paired with the sensor controller. Thus, in this example, the sensor controller transmits the downlink time slot allocation to the active stylus by transmitting Hash#2 in a beacon signal in response to receipt of Hash#1. In another example, the sensor controller may transmit a predefined code indicative of a particular downlink time slot allocation to the active stylus, wherein the sensor controller and the active stylus share a list of predefined codes and what downlink time slot allocation each code indicates. In this example, the sensor controller transmits the downlink time slot allocation to the active stylus by transmitting one of the predefined codes in a beacon signal. As yet another example, the sensor controller may transmit the downlink time slot allocation by transmitting, for example, an offset value and an interval value that specify the positions of downlink time slots allocated to the active stylus per frame, as will be more fully described below in reference to FIGS. 9A-9G. In this example, the sensor controller transmits the downlink time slot allocation to the active stylus by transmitting an offset value and an interval value, for example, in a beacon signal.

In FIG. 8B, the beacon signal in time slot s0 of frame Fn+1 includes the downlink time slot allocation determined for the active stylus. Thus, the active stylus reads the beacon signal to determine the downlink time slot allocation, and starts transmitting data packets (DP), which include the stylus's operational data, in time slot s2 of frame Fn+1 according to the determined downlink time slot allocation.

FIGS. 9A-9G illustrate seven different frame formats, in which an active stylus transmits packets to the sensor controller according to seven different kinds of downlink time slot allocation specified by the sensor controller, respectively. In each of FIGS. 9A-9G, the beacon signal in time slot s0 of frame Fn+1 includes the downlink time slot allocation determined for the active stylus, and thus the active stylus can transmit packets (data packets and/or position packets) to the sensor controller starting at time slot s1 of frame Fn+1 according to the determined downlink time slot allocation.

In FIG. 9A, the downlink time slot allocation specifies that the active stylus is to transmit data packets including operational data (e.g., 14 bits) starting at time slot s2 of frame Fn+1 at equal intervals (T) of four (4) time slots, i.e., in time slots s6, s10 and s14 in frame Fn+1 and in time slots s2, s6, s10 and s14 in frame Fn+2, and so forth. In this case, the sensor controller may define the downlink time slot allocation by specifying: i) an offset value indicative of a starting time slot for use by the active stylus to transmit packets, and ii) an interval value indicative of intervals between time slots allocated to the active stylus beginning with the starting time slot. For example, the downlink time slot allocation of the example of FIG. 9A may be specified by an offset of “2” indicating that the starting time slot is s2, and an interval value of “4” indicating that subsequent time slots at equal intervals (T) of 4 time slots are to be used by the active stylus. The sensor controller may encode these values (offset: 2, interval: 4) in a beacon signal to thereby transmit the downlink time slot allocation to the active stylus. The downlink time slot allocation may additionally specify, for example, a total number of packets to be transmitted (e.g., “5” (DP1˜DP5) in the example of FIG. 9A) and/or a data format of the packets (e.g., how many total bits per packet, of which how many bits indicate pen pressure data and how many bits indicate barrel pressure data, etc.).

FIG. 9A also illustrates that time slot s1 of each frame Fn+1, Fn+2, and so forth, is reserved as a downlink time slot for the active stylus to optionally send its stylus capability information (CP) to the sensor controller. For example, when the user adjusts the setting of the active stylus (e.g., the user changes the stylus line width) during a bidirectional communication session with the sensor controller, the active stylus may send the adjusted setting information to the sensor controller in time slot s1 of a subsequent frame. Additionally or alternatively, when the beacon signal from the sensor controller includes a read command requesting stylus capability information of the active stylus, in response the active stylus includes the requested capability and/or setting information in time slot s1 of a subsequent frame.

FIG. 9A further illustrates that time slot s15 of frame Fn+1 is reserved as a downlink time slot for the active stylus to send a data packet including operational data that is polled (requested) in a preceding beacon signal from the sensor controller. For example, when the beacon signal in time slot s0 of frame Fn+1 requests the active stylus to report its battery level, in response the active stylus sends a data packet including the polled operational data (“Poll DP”) in time slot s15 of frame Fn+1.

In FIG. 9B, the downlink time slot allocation specifies that the active stylus is to transmit data packets including operational data (e.g., 14 bits) starting with time slot s3 of frame Fn+1 at equal intervals (T) of four (4) time slots, i.e., in time slots s7, s11 and s15 in frame Fn+1 and in time slots s3, s7, s11 and s15 in frame Fn+2, and so forth. Similarly to the example of FIG. 9A described above, the downlink time slot allocation of the example of FIG. 9B may be specified by an offset of “3” indicating that the starting time slot is s3, and an interval value of “4” indicating that subsequent time slots to be used are at equal intervals (T) of 4 time slots. FIG. 9B also illustrates that time slot s1 of each frame Fn+1, Fn+2, and so forth, is reserved as a downlink time slot for the active stylus to optionally send stylus capability information (CP) to the sensor controller. Furthermore, when the beacon signal in time slot s0 of frame Fn+1 polls (requests) the active stylus to report certain operational data of the active stylus, such as the stylus's battery level, in response the active stylus sends a data packet including the polled operational data (“Poll DP”) in time slot s1 of frame Fn+1.

In various embodiments, one or more time slots (e.g., s1) after the beacon signal time slot (s0) in each frame is reserved for the active stylus to send a response signal (e.g., an ACK signal) to acknowledge receipt of the beacon signal in the preceding time slot (s0). Thus, a “response signal” as used herein is not limited to the first response signal that the active stylus transmits upon entering the sensing zone of the sensor controller in response to the initial (discovery) beacon signal. Instead, response signals may include subsequent response signals, which the active stylus transmits in response to subsequent beacon signals including various commands or other information directed to the active stylus. For example, the active stylus may transmit a response signal responsive to a subsequent beacon signal including a new downlink time slot allocation, which has been updated by the sensor controller during the bidirectional communication session due to changed setting of the active stylus. As another example, when a subsequent beacon signal includes a read command requesting the active stylus to transmit stylus capability information, the active stylus sends a response signal including the requested stylus capability information (see FIG. 9A, wherein “CP” sent in time slot s1 of frames Fn+1 and Fn+2 may be considered a response signal including the requested stylus capability information). As a further example, when a subsequent beacon signal includes a polling command requesting the active stylus to transmit certain operational data (e.g., stylus battery level) of the active stylus, the active stylus sends a response signal including the polled operational data (see FIG. 9B, wherein “Poll DP” sent in time slot s1 of frame Fn+1 may be considered a response signal including the polled operational data).

In FIG. 9C, the downlink time slot allocation specifies that the active stylus is to transmit relatively large data packets (e.g., more than 14 bits) starting at time slot s2 of frame Fn+1, in a unit of two (2) time slots, at equal intervals (T) of four (4) time slots, i.e., in time slots [s2/s3], [s6/s7], [s10/s11] and [s14/s15] in frame Fn+1, frame Fn+2, and so forth. The downlink time slot allocation of the example of FIG. 9C may be specified by an offset of “2” indicating that the starting time slot is s2, an interval value of “4” indicating that subsequent time slots to be used are at equal intervals (T) of 4 time slots, and additionally by a unit size value of “2” indicating that a unit of 2 time slots is used to form each of the data packets (DP1, DP2, DP3, DP4, DP5, etc.). The unit size value of “2” may be considered as a packet length to be used by the active stylus. Such relatively large data packets may be needed, for example, to transmit customized operational data (CD) of the active stylus to the sensor controller.

As in FIGS. 9A and 9B, FIG. 9C also illustrates that time slot s1 of each frame Fn+1, Fn+2, and so forth, is reserved as a downlink time slot for the active stylus to optionally send stylus capability information (CP) to the sensor controller. FIG. 9C further illustrates that, when the beacon signal in time slot s0 of frame Fn+1 polls (requests) the active stylus to report certain operational data (e.g., stylus battery level), in response the active stylus sends a data packet including the polled operational data (“Poll DP”) in time slot s1 of frame Fn+1.

FIG. 9D illustrates a combination of a first downlink time slot allocation that assigns frequency f0 to a first active stylus, and a second downlink time slot allocation that assigns frequency f1 different from frequency f0 to a second active stylus different from the first active stylus.

The first downlink time slot allocation specifies that the first active stylus, operating at frequency f0, is to transmit relatively large data packets (e.g., a data packet including stylus orientation data (OR) that occupies two time slots per frame: see ORC 1 or 3 in FIG. 4C) starting at time slot s2 of frame Fn+1, in a unit of three (3) time slots, at equal intervals (T) of eight (8) time slots, i.e., in time slots [s2/s3/s4] and [s10/s11/s12] in frame Fn+1, frame Fn+2, and so forth. The first downlink time slot allocation may be specified by an offset of “2” indicating that the starting time slot is s2, an interval value of “8” indicating that subsequent time slots to be used are at equal intervals (T) of 8 time slots, and a unit size value (or packet length) of “3” indicating that a unit of 3 time slots is used to form each of the data packets (DP1, DP2, DP3, etc.).

The second downlink time slot allocation specifies that the second active stylus, operating at frequency f1, is also to transmit relatively large data packets (e.g., a data packet including stylus orientation data (OR) that occupies three time slots per frame: see ORC 2 or 4 in FIG. 4C) starting at time slot s2 of frame Fn+1, in a unit of four (4) time slots, at equal intervals (T) of eight (8) time slots, i.e., in time slots [s2/s3/s4/s5] and [s10/s11/s12/s13] in frame Fn+1, frame Fn+2, and so forth. The second downlink time slot allocation may be specified by an offset of “2” indicating that the starting time slot is s2, an interval value of “8” indicating that subsequent time slots to be used are at equal intervals (T) of 8 time slots, and a unit size value (or packet length) of “4” indicating that a unit of 4 time slots is used to form each of the data packets (DP1, DP2, DP3, etc.).

In FIG. 9D, as in previous examples, time slot s1 of each frame Fn+1, Fn+2, and so forth, is reserved as a downlink time slot for both of the first active stylus operating at frequency f0 and the second active stylus operating at frequency f1 to optionally send stylus capability information (CP) to the sensor controller. FIG. 9D further illustrates that, when the beacon signal in time slot s0 of frame Fn+1 polls (requests) either of the first or second active stylus to report certain operational data (e.g., stylus battery level), in response the polled active stylus sends a data packet including the polled operational data (“Poll DP”) in time slot s15 of frame Fn+1. In the example of FIG. 9D, the beacon signal in time slot s0 of frame Fn+1 polled the first active stylus operating at frequency f0 and, thus, the first active stylus responds by transmitting a data packet including the polled operational data (“Poll DP”) in time slot s15 of frame Fn+1.

Once the sensor controller assigns a particular frequency (e.g., f0, f1) to each of multiple active styluses, the sensor controller may include a command directed to a particular active stylus only in a frequency portion of the beacon signal assigned to that active stylus.

In FIG. 9E, which is similar to FIG. 9A, the downlink time slot allocation specifies that the active stylus is to transmit data packets including operational data (16 bits) starting at time slot s2 of frame Fn+1 at equal intervals (T) of four (4) time slots, i.e., in time slots s6, s10 and s14 in frame Fn+1 and in time slots s2, s6, s10 and s14 in frame Fn+2, and so forth. The downlink time slot allocation of this example may be specified by an offset of “2” indicating that the starting time slot is s2, and an interval value of “4” indicating that subsequent time slots to be used are at equal intervals (T) of 4 time slots. FIG. 9E also illustrates that time slot s1 of each frame Fn+1, Fn+2, and so forth, is reserved as a downlink time slot for the active stylus to optionally send stylus capability information (CP) to the sensor controller. FIG. 9E further illustrates that, when the beacon signal in time slot s0 of frame Fn+1 polls (requests) the active stylus to report certain operational data (e.g., stylus battery level), in response the active stylus sends a data packet including the polled operational data (“Poll DP”) in time slot s15 of frame Fn+1.

The downlink time slot allocation examples of FIGS. 9A-9E all specify downlink transmission of data packets (DP1, DP2, DP3, DP4, DP5, etc.) which include operational data of the active stylus. On the other hand, the downlink time slot allocation of FIG. 9F specifies not only which downlink time slots to use in a frame but also what types of packets (data packets (DP) or position packets (XY)) the active stylus should transmit in which downlink time slots.

Specifically, the downlink time slot allocation of FIG. 9F specifies that the active stylus is to transmit position packets (XY), which are to be used by the sensor controller to determine a position pointed to by the active stylus on the sensor 201, starting at time slot s2 of frame Fn+1 at equal intervals (T) of four (4) time slots, i.e., in time slots s2, s6, s10 and s14 of each frame. The downlink time slot allocation further specifies that each position packet (XY) is immediately followed by a data packet (DP1, DP2, DP3, DP4, DP5, etc.) transmitted in time slots s3, s7, s11 and s15 of each frame. Thus, a unit of two time slots [s2/s3], [s6/s7], [s10/s11] and [s14/s15] is used to transmit a position packet (XY) and a data packet (DP). The downlink time slot allocation of the example of FIG. 9F may be specified by an offset of “2” indicating that the starting time slot is s2, an interval value of “4” indicating that subsequent time slots to be used are at equal intervals (T) of 4 time slots, a unit size value of “2” indicating that a unit of 2 time slots is used to transmit a position packet (XY) and a data packet (DP) in succession, and a packet type value indicative of what type of packet is transmitted in each unit. For example, a packet type value 0 may indicate only data packets are transmitted in each unit (DP/DP), 1 may indicate only position packets are transmitted in each unit (XY/XY), 2 may indicate that a position packet immediately followed by a data packet are transmitted in each unit (XY/DP) as in the example of FIG. 9F, and 3 may indicate that a data packet immediately followed by a position packet are transmitted in each unit (DP/XY).

As in the previous examples of downlink time slot allocation, FIG. 9F also illustrates that time slot s1 of each frame Fn+1, Fn+2, and so forth, is reserved as a downlink time slot for the active stylus to optionally send stylus capability information (CP) to the sensor controller.

It should be noted that the downlink time slot allocation of FIGS. 8A-9G are examples only, and the present invention is not limited to using the particular examples of FIGS. 8A-9G.

Operating systems and applications running on the host controller 300 side often use smoothing on the data provided by the sensor controller 200. This includes smoothing on coordinate data produced by the sensor controller 200 as well as stylus data such as pressure or tilt. In many cases the algorithms of the applications assume the data is measured at equally spaced time intervals when applying the smoothing. There may be situations where the sensor controller 200 is unable to provide time slot allocations that provide equally spaced position packets or equally spaced data packets. In these cases the sensor controller 200 may have to sub-sample, super-sample, interpolate, extrapolate, or by some means adjust the data such that the data appears at equally spaced time intervals. This technique also applies when coordinates and/or operational data is measured at different rates due to the time slot allocations. Data packets from the sensor controller 200 to the host processor 300 have no way to indicate missing data, so missing data needs to be generated as above (e.g., by sub-sampling, super-sampling, interpolation, extrapolation, etc.) to fill these intermediate packets with valid data. For example, if orientation data is available at half the rate of coordinate data, the orientation data needs to be super-sampled or extrapolated to twice the data rate to match the coordinate data rate.

FIG. 10 is a flowchart illustrating a sample pairing operation (and “fast inking” operation) between an active stylus and a sensor controller, in which the active stylus transmits a hash value (“Hash#1”) indicative of its setting information to the sensor controller. The sensor controller, after recognizing the received Hash#1, returns a second hash value (“Hash#2”) to the active stylus, as further verification that it has correctly recognized the active stylus as a previously-paired stylus.

If the sensor controller recognizes the received Hash#1 (meaning that the sensor controller has been previously paired with the active stylus), the sensor controller may speed up the pairing operation using the stylus capability information and/or the downlink time slot allocation of the active stylus already cached in the sensor controller.

In step S301, the active stylus applies a hashing operation to its setting information, for example, to calculate a hash value (“Hash#1”) of a fixed size (e.g., 16 bits), which can be transmitted in a single time slot which typically accommodates up to 20 bits. In step S302, the active stylus calculates a second hash value (“Hash#2”), which corresponds to Hash#1 and thus can be used to verify Hash#1, as will be more fully described below. Hash#1 and Hash#2 may be calculated at power up and any time a change takes place that affects the hash value, such as when a user changes the setting (e.g., stylus line width) of the active stylus. Any suitable hashing operation may be used to calculate Hash#1 and Hash#2. For example, MurmurHash3™ algorithm, known in the art, may be used to calculate a 32-bit hash value based on capability information of any length. Then, the 16 LSBs of the hash value may be used as Hash#1 and the 16 MSBs of the hash value may be used as Hash#2. The calculated Hash#1 and Hash#2 are stored in the active stylus, for example in the table (TBL) of the stylus capability information manager 110 (see FIG. 1).

A hashing operation may be applied to some or all of the stylus capability information of the active stylus. For example, in order to reduce the possibility of hash collision in which the same hash value is calculated for two active styluses or for two different settings of one active stylus, it may be desirable to exclude capability information from the hash calculation because capability information may be common amongst multiple active styluses manufactured by the same vendor. Thus, in various exemplary embodiments, the active stylus calculates Hash#1 and Hash#2 based on the setting information portion of the stylus capability information of the active stylus and a global ID of the active stylus, to create a unique “Hash ID” of the active stylus that is unlikely to collide with a Hash ID of another active stylus or of the same active stylus having different setting. In some embodiments of the present invention, two hashing functions may be used to calculate Hash#1 and Hash#2, respectively, to further reduce the potential for hash collisions. For example, Hash#1 may be calculated using algorithm 1 on the stylus capability information, such as a variation of CRC (cyclic redundancy check) adjusted to produce a 13-bit hash value, and Hash#2 may be calculated using algorithm 2 on the stylus capability information, such as a variation of FNV (Fowler-Noll-Vo) adjusted to produce a 16-bit hash value.

In step S401, the sensor controller sends a beacon signal (BS). In step S303, when the active stylus detects the beacon signal, in step S304, the active stylus sends Hash#1 calculated in step S301 above to the sensor controller as part of a response signal.

In step S403, when the sensor controller detects the response signal from the active stylus, in step S405, the sensor controller determines if Hash#1 included in the response signal is already cached in the sensor controller. If not, in step S407, the sensor controller sends a read command in a subsequent beacon signal to request the active stylus to transmit its complete (non-hashed) stylus capability information (CP). In step S305, the active stylus, in response to the read command from the sensor controller, transmits the requested stylus capability information (CP) to the sensor controller. The sensor controller, in step S409, computes Hash#1 and Hash#2 based on the received stylus capability information (CP) and stores them in cache for future use. Alternatively, in step S409, the sensor controller calculates only Hash#2 and stores the calculated Hash#2 with Hash#1 that was received and evaluated in step S405 above. In step S409 the sensor controller uses the same hashing operation to calculate Hash#1 and Hash#2 as that used in steps S301 and S302 by the active stylus.

Returning to step S405, if the sensor controller determines that Hash#1 included in the response signal from the active stylus is already cached in the sensor controller, Hash#2 corresponding to Hash#1 is also cached in the sensor controller (see step S409). Thus, in step S411, the sensor controller sends Hash#2 corresponding to Hash#1 back to the active stylus for verification purposes. Specifically, in step S307, the active stylus determines whether Hash#2 returned from the sensor controller matches Hash#2 cached in the active stylus, which corresponds to Hash#1 that the active stylus has sent in step S304 above. If yes, the active stylus confirms that the sensor controller has correctly recognized the active stylus as the one that the sensor controller has been previously paired with. Then, in step S309, the active stylus sends a response signal to the sensor controller to verify that the sensor controller already has the stylus capability information (including the setting information) and/or the downlink time slot allocation of the active stylus. In step S413, the sensor controller receives the response signal from the active stylus and concludes the verification process. At this point, both of the active stylus and the sensor controller are ready to start bidirectional communication using the same downlink time slot allocation they used when they were previously paired. Also at this time, the sensor controller may immediately start “inking” operation because it has all the setting information (e.g., brush style, line width, line color, etc.) of the active stylus that an application program needs to start drawing lines formed by the active stylus.

If, in step S307, the active stylus determines that Hash#2 received from the sensor controller does not correspond to Hash#2 stored in the active stylus, in step S311 the active stylus sends a failure message (FAIL) to the sensor controller to indicate verification failure, and returns to step S303 to resume listening for beacon signals from the sensor controller.

In step S413, the sensor controller is notified of verification failure either by receiving the failure message (FAIL) sent from the active stylus (step S311) or by not receiving the response signal indicative of successful verification from the active stylus (step S309). When verification fails, the sensor controller returns to step S407 to request the active stylus to transmit its complete (non-hashed) stylus capability information (CP).

FIG. 11 is a diagram, similar to FIG. 1, illustrating an overall system including an active stylus 100 and an electronic device (e.g., PC, tablet computer, smartphone) 3. FIG. 11 particularly illustrates bidirectional communications between the sensor controller 200 and the host processor 300 within the electronic device 3.

The sensor controller 200 includes processing circuitry 202, to which are coupled sensor reception (RX) circuitry, sensor transmission (TX) circuitry, and a memory device. The host processor 300 includes processing circuitry 301, which is coupled to host reception (RX) circuitry and host transmission (TX) circuitry. Bidirectional communications, from the host transmission (TX) circuitry to the sensor reception (RX) circuitry in one direction, and from the sensor transmission (TX) circuitry to the host reception (RX) circuitry in the other direction, may be supported by a Universal Serial Bus (USB) interface (the USB HID-PTCL), or by an Inter-Integrated Circuit (I2C) bus, Serial Peripheral Inter face (SPI) bus, or other suitable hardware interface

Referring additionally to FIG. 12A, a method of communication between the sensor controller 200 and the host processor 300 includes generally three steps. First, in step S1202, the sensor controller that supports a default descriptor of a defined set of stylus attributes transmits the default descriptor to the host processor 300. The default descriptor is specified and supported by the processing circuitry 202 of the sensor controller 200. Briefly, a default descriptor defines a format of a HID (Human Interface Device) class report that is sent by the sensor controller 200 to the host processor 300. In other words, a default descriptor defines what information is included in what format in such report. In various embodiments the defined set of stylus attributes in the default descriptor includes all (possible) stylus attributes that may be supported by different types of active styluses. As will be more fully described below, this allows a newly discovered stylus 100 to provide a minimum set or a full range of all possible stylus attributes supported by the default descriptor depending on the active stylus's capabilities and preferences.

FIG. 13 is a sample default descriptor for a stylus report to be sent from the sensor controller 200 to the host processor 300. A stylus report includes stylus attributes as reported from the active stylus 100, such as the stylus's position, tip pressure value, barrel pressure value, stylus orientation value (e.g., tilt and rotation), etc. FIG. 14 is a table of the stylus attributes included in the default descriptor of FIG. 13. As shown in FIG. 14, stylus attributes include: stylus coordinate values (“X, Y”); a stylus local ID (“Transducer Index”) assigned to each stylus while the stylus is in range of the sensor's sensing zone; stylus pressure values including at least one of a tip pressure value (“Tip Pressure”) and a barrel pressure value (“Barrel Pressure”); stylus switch (switch status) values including at least one of a tip switch value (“Tip Switch”), a first barrel switch value (“Barrel Switch”), and a second switch value (“Secondary Barrel Switch”); a stylus inversion indicator value (“Invert”) indicating whether the stylus is inverted from its intended orientation (i.e., the stylus tip is pointed upwardly); a stylus eraser indicator (“Erase”) indicating whether one tip (e.g., the inverted tip) of the stylus is functioning as an eraser; a stylus in-range value (“In Range”) indicating whether the stylus is within the sensing zone of the sensor surface; stylus orientation values including at least one of an X tilt value (“X Tilt”), a Y tilt value (“Y Tilt”), a twist value (“Twist”), an altitude value, an azimuth value, an accelerometer value, a gyroscope value, and a magnetometer value; a stylus battery status value (“Battery Strength”); a stylus global ID (“Transducer Serial Number”); a stylus preferred color value (“Preferred Color”) indicating an original color set in a memory of the active stylus (which may be subsequently changed by the stylus user or by the sensor controller/host processor, as will be described below); a stylus preferred line width value, indicating what line width the active stylus would prefer to render; a stylus preferred line style value, indicating in what style the active stylus would prefer to render (e.g., inking pen, pencil, highlighter, chisel tip marker, brush, etc.); and custom attributes that can be set by an active stylus vendor/manufacturer (“Vendor Usage”).

Introduction of a preferred color value, a preferred line width value, and a preferred line style value is technically advantageous to be set in the active stylus 100, which may be freely set and changed in the active stylus 100 (by the user operating on one of the switches provided on the active stylus 100 for example). In the prior art, these values were typically controlled solely by the application 302 (e.g., drawing application) operating on the host processor 300. In the prior art, thus, the active stylus 100 was used mostly as a device that inputs position coordinates and pressure data and was not allowed to dictate its color, line width, line style, etc. As styluses become more widespread there is more likelihood for the same stylus to be used in multiple applications or on multiple systems. When moving between applications or systems it would be more intuitive for the user if the virtual on-screen ink is consistent between these applications and systems. The embodiments of the invention, by allowing the active stylus 100 to indicate its attributes such as its preferred color, line width and/or line style, facilitates the application 302 operating on the host processor 300 to render the virtual on-screen ink consistently in accordance with the user's preference. According to various embodiments of the present invention, these values that affect the appearance of the virtual on-screen ink can be freely set and adjusted in the active stylus 100 based on the user operation on the active stylus 100 or based on commands from the application 302 operating on the host processor 300, as will be described below.

Further details of seventeen (17) of the stylus attributes as defined in the default descriptor according to one particular example are set forth below.

1. Report ID:

-   -   The Report ID can be changed to other IDs as appropriate.

2. Coordinates (Usage(X) and Usage (Y)):

-   -   Since the sensor controller 200 has complete knowledge of the         attached sensor, the Physical Maximum, Unit, and Unit Exponent         should be changed to reflect the actual physical size and         resolution of the sensor.     -   Also, the Logical Maximum should indicate the true maximum         values output by the sensor controller 200 for the sensor.     -   If the Logical Maximum is larger than 65535, the report size may         be increased and padding added if necessary.

3. Transducer Index (Usage(Transducer Index)):

-   -   When multiple styli are simultaneously tracked, the Transducer         Index indicates which stylus 100 produced the report.     -   A unique Transducer Index is assigned to a stylus 100 when it is         detected and persists until it leaves range.     -   The Transducer Index is arbitrary. Values may be reused.

4. Tip Pressure (TiP) (Usage(Tip Pressure)):

-   -   The Tip Pressure value output by the stylus 100 is a 12 bit         value.

5. Barrel Pressure (Usage(Barrel Pressure)):

-   -   The Barrel Pressure value output by the stylus 100 is a 12 bit         value.     -   If the stylus 100 does not support Barrel Pressure, the value         reported is set to maximum (4095).     -   Rationale: Barrel pressure is used to change a brush dynamic,         such as opacity. By setting Barrel Pressure to maximum the full         effect of the brush dynamic is applied.

6. Tip Switch (Usage(Tip Switch):

-   -   The sensor controller 200, not the stylus 100, generates the Tip         Switch bit in the following manner.     -   Rationale: In order to eliminate the need for the stylus 100 to         send the Tip Switch bit, the sensor controller 200:

i). sets the Tip Switch to 0 if the tip pressure reported by the stylus 100 is zero; otherwise sets the Tip Switch to 1.

ii). does not set the Tip Switch if the Invert bit is set (instead the Eraser bit is set when reported tip pressure is non-zero).

7. Barrel Switches (BB) (Usage(Barrel Switch) and Usage(Secondary Barrel Switch)):

-   -   If one of the barrel switches is dedicated to an eraser         affordance, it is not reported as a barrel switch by the stylus         100. Instead it is reported as an Invert bit. This is done in         the stylus 100.     -   Secondary Barrel Switch is a relatively new HID usage that may         not be supported in operating system-provided data parsers.

8. Invert (Inv) (Usage(Invert)):

-   -   The stylus 100 provides the Invert bit, not the sensor         controller 200. This bit is set when the eraser affordance is in         use, meaning either the tail end of the stylus 100 is closest to         the surface (if there is an eraser switch and sensor in the         tail) or that the barrel button dedicated to erasing is pressed.

9. Eraser (Usage(Eraser)):

-   -   The sensor controller 200, not the stylus 100, handles the         following functionality.     -   Rationale: In order to eliminate the need for the stylus 100 to         send the Eraser bit, the sensor controller 200:

i). sets the eraser bit to 0 if the Invert bit is set to 0.

ii). sets the eraser bit to 0 if the Invert bit is set to 1 and the Tip Pressure reported by the stylus 100 is zero;

iii) sets the eraser bit to 1 if the Invert bit is set to 1 and the Tip Pressure reported by the stylus 100 is not zero.

10. In Range (Usage(In Range)):

-   -   The sensor controller 200 generates the In Range bit.     -   The sensor controller 200 sets the In Range bit in a report         after the sensor controller 200 detects a stylus 100.     -   All subsequent reports while receiving data from the stylus 100         will have In Range set.     -   At least one report with In Range clear may be sent when the         stylus 100 is no longer detected.

11. Orientation (OR) (Usage(X Tilt), Usage(Y Tilt), and Usage(Twist)):

-   -   Any orientation values not supported by the stylus 100 are         reported as zero.     -   If orientation from the stylus 100 is reported as Altitude and         Azimuth, they are converted by the sensor controller 200 to X         Tilt and Y Tilt.     -   IMU values will be converted by the sensor controller 200 to         Tilt and Twist values.     -   Tilt values have a physical range from −90 to 90 degrees,         although they may be reported in radians if so desired.     -   Twist values have a physical range from 0 to 360 degrees,         although they may be reported in radians if so desired.     -   The physical and logical ranges may be such that there are two         decimal places of resolutions for degrees, or four decimal         places for radians.

12. Battery Level (BL) (Usage(Battery Strength)):

-   -   Battery Level is reported in percent full.     -   The level reported by the stylus 100 may have 16 levels and may         need to be scaled.     -   Battery level is computed as follows: Battery Strength=stylus         100 level*(100/16).

13. Serial Number (SN) (Usage(Transducer Serial Number)):

-   -   The Serial Number is the 56 bit Serial Number from the stylus         100 with the 8 bit Vendor ID from the stylus 100 prepended to         make a 64 bit value.     -   Serial Number is a relatively new HID usage that may not be         supported in operating system-provided data parsers.

14. Preferred Color (Col) (Usage(Preferred Color)):

-   -   The preferred color from the stylus 100 capabilities is placed         in the preferred Color (Col). If there is no preferred color         from the stylus 100 the usage is filled in with 0xFF (no         preference).     -   Since the preferred Color is not changed so frequently from         stylus down to stylus up, this information is preferred to be         included in Full Report (FIG. 14) and not to be included in         Short Report (FIG. 14).

15. Preferred Line Width:

-   -   This may be an indication of the physical width of the tip of a         stylus. The descriptor is expected to include logical and         physical minimums and maximums. A recommended physical         resolution is 0.1 mm. A zero line width may indicate minimum         possible width (such as one pixel width at any zoom factor).

16. Preferred Line Style:

-   -   An indication of what line style the stylus would prefer to         render. This may be an indication of the physical         characteristics of the stylus.

17. Vendor Defined Data and Usage (Usage Page(Vendor Defined Usage Page 1) Usage(Vendor Usage 2)):

-   -   One or two custom bytes received from the stylus 100 are placed         into the vendor defined usage at the end of the report.     -   Any unused bytes are set to zero.

Referring back to FIG. 12A, in step S1202, the sensor controller 202 transmits, via the sensor TX circuitry, the default descriptor to the host processor 300, via the host RX circuitry. In various exemplary embodiments the transmission of the default descriptor to the host processor 300 occurs when connection between the sensor controller 200 and the host processor 300 is established. The host processor 300, having received the default descriptor, can thereafter process and receive various stylus reports supported by the default descriptor and sent from the sensor controller 200.

In step S1203, the sensor controller 200, when coupled with a first active stylus 100A (see FIG. 11) capable of reporting on a first subset of the defined set of stylus attributes as included in the default descriptor, transmits to the host processor 300 a first stylus report that is defined by the default descriptor and that has fields of the first subset of stylus attributes filled with values 113A reported from the first active stylus 100A. In step S1204, the sensor controller 200, when coupled with a second active stylus 100B capable of reporting on a second subset of the defined set of stylus attributes different from the first subset, transmits to the host processor 300 a second stylus report that is defined by the default descriptor and that has fields of the second subset of stylus attributes filled with values 1138 reported from the second active stylus 100B. For example, the first active stylus 100A may be capable of reporting on substantially all of the stylus attributes as defined in the default descriptor, while the second active stylus 100B may be capable of reporting on only a few of the stylus attributes (e.g., position and pen pressure). The first and second subsets of stylus attributes may differ in terms of the types of stylus attributes included in the first and second subsets, respectively, and/or the number of stylus attributes included in the first and second subsets, respectively. Regardless of the capability of the active stylus used with the sensor controller 200, the sensor controller 200 can prepare a stylus report, based on the stylus attributes reported from the particular active stylus 100, and send the stylus report to the host processor 300. Since all stylus reports sent from the sensor controller 200 are supported by the default descriptor, though some reports include more stylus attributes reported from the styluses than other reports, the host processor 300 that has received the default descriptor can interpret and process all such stylus reports.

In some cases the active stylus 100 may be capable of reporting on the entire stylus attributes defined in the default descriptor. In such cases the subset of stylus attributes equals the defined set of stylus attributes included in the default descriptor. In other cases, different active styluses (100A, 100B) respectfully support different subsets of stylus attributes that are both less than the defined set of stylus attributes included in the default descriptor.

FIG. 12B is another flowchart illustrating a method of communication between the sensor controller 200 and the host processor 300 based on a default descriptor that supports transmission of stylus reports including various sets of stylus attributes. In step S1211, the sensor controller 200 transmits a default descriptor of a defined set of stylus attributes to the host processor 300. In step S1212, the sensor controller 200 receives stylus attributes from the active stylus 100. In step S1213, the sensor controller 200 determines what (which) subset of the stylus attributes has been received. If a first subset of stylus attributes has been received, then in step S1214, the sensor controller 200 generates a first stylus report supported by the default descriptor and filled with the received values of the first subset of stylus attributes. If, on the other hand, a second subset of stylus attributes (different from the first subset) has been received, in step S1216, the sensor controller 200 generates a second stylus report supported by the default descriptor and filled with the received values of the second subset of stylus attributes. In either case, in step S1215 or in step S1217, optionally, the sensor controller 200 may complete the report by filling any fields in the report for stylus attributes not reported from the active stylus 100 with default values and/or by applying a suitable smoothing algorithm to fill those (non-reported) fields with “smoothed” data, as will be more fully described immediately below. In step S1218, the generated first or second stylus report, which may optionally be filled with default and/or smoothed data, is transmitted to the host processor 300.

When the sensor controller 200 is coupled with an active stylus not capable of reporting on all of the defined set of stylus attributes defined by the default descriptor, the sensor controller 200, in creating a stylus report, may fill default values in fields in the report for stylus attributes not reported from the active stylus. The default values may be predefined, or calculated according to a predefined algorithm. For example, when any of the stylus attributes defined in the default descriptor are not supported by, and thus not reported from a particular active stylus, the report fields for those stylus attributes may be filled with default values (e.g., maximum values) to indicate that the particular stylus attributes are not supported/reported by the active stylus. As another specific example, if an active stylus has no preferred color, a report field for the preferred color may be set to a default value indicating that there is no preferred color.

In various exemplary embodiments, the sensor controller 200 applies a smoothing algorithm to the stylus attributes reported from the active stylus 100 to fill fields in a stylus report. For example, the sensor controller 200 may apply one or more of sub-sampling, super-sampling, interpolation, or extrapolation processing to the stylus attributes reported from the active stylus 100. Such smoothing includes smoothing on coordinate data produced by the sensor controller 200 based on signals from the active stylus 100 as well as stylus attributes reported from the active stylus 100. Operating systems and applications (302 in FIG. 11) operating on the host processor 300 typically assume that the data reported from the active stylus 100 via the sensor controller 200 occurs at equal time intervals. Thus, if the sensor controller 200 does not receive stylus attributes at equal intervals, the sensor controller 200 may apply suitable smoothing algorithm to generate missing data so that the data reported to the host processor 300 will appear at equally spaced time intervals. In other embodiments, a smoothing algorithm may be alternatively or additionally applied by the application (302 in FIG. 11) running on the host controller 300.

The sensor controller 200, when creating a stylus report, may convert a format of any stylus attribute reported from the active stylus 100 to a format suitable for inclusion in the stylus report. For example, when a preferred color (1300 in FIG. 13) of the active stylus 100 is reported in a first format (e.g., 16 bits to indicate one of 65536 RBG565 format colors), the sensor controller 200 may convert it to a second format (8 bits to indicate one of 140 CSS (Cascading Style Sheet) colors) suitable for the stylus report. The sensor controller 200 may then include the preferred color in the second format in the stylus report to be sent to the host processor 300.

Referring back to FIG. 14, in another embodiment, the default descriptor may include a first description of a defined set of stylus attributes, which supports a “Full Report,” and a second description of a subset of the defined set of stylus attributes, which supports a “Short Report.” FIG. 15 is a sample second description of a subset of the defined set of stylus attributes in the default descriptor of FIG. 13, which supports the Short Report. As shown, the second description includes a fewer number of stylus attributes. In FIG. 14, “X” indicates that a particular stylus attribute is included in the Full Report and/or in the Short Report, illustrating that a fewer number of stylus attributes are included in the Short Report as compared to the Full Report. As such, in various exemplary embodiments, the Short Report has a smaller data size than the Full Report. If an active stylus 100 only provides stylus attributes included in the Short Report, the sensor controller 200 may generate and send the Short Report having a smaller data size instead of the Full Report. If the active stylus 100 provides any stylus attribute not included in the Short Report, the sensor controller 200 generates and sends the Full Report.

In the embodiment in which the Full and Short Reports are used, the sensor controller 200, when coupled with a first active stylus 100A capable of reporting on substantially the defined set of stylus attributes, transmits to the host processor 300 a Full Report that is defined by the first description included in the default descriptor and that has fields of substantially the defined set of stylus attributes filled with values reported from the first active stylus 100B. The sensor controller 200, when coupled with a second active stylus 100B capable of reporting on substantially the subset of stylus attributes, transmits to the host processor 300 a Short Report that is defined by the second description included in the default descriptor and that has fields of substantially the subset of stylus attributes filled with values reported from the second active stylus 1006. As used herein, reporting on “substantially” a set of attributes means reporting on all or substantially all of the set of attributes. For example, in FIG. 14, the Full Report includes 18 stylus attributes, and the Short Report includes 10 stylus attributes. When an active stylus supports all 10 of the Short Report attributes and at least one additional attribute, the sensor controller 200 generates a Full Report for the active stylus including 11 to 18 attributes. That is, even if the active stylus supports only 11 attributes, a Full Report is generated and is considered to include “substantially” the defined set of attributes. According to the embodiment, depending on the capability of a particular active stylus 100, the sensor controller 200 generates either a Full Report or a Short Report, whichever is suited to substantially report the stylus attributes reported from the active stylus. In this embodiment also, since not all stylus attributes included in either the Full or Short Report may be reported from the active stylus, the sensor controller 200 may fill default values in fields in the selected Report for stylus attributes not reported from the active stylus. Also, the sensor controller 200 may apply a smoothing algorithm (sub-sampling, super-sampling, interpolation, extrapolation, etc.) to the stylus attributes reported form the active stylus to fill fields in the selected Report. The sensor controller 200 may use the stylus capability information that indicates attributes supported by the active stylus 100, as reported from the active stylus 100, to select which of the Full or Short Report to use. (See 114 in FIG. 11.)

Referring to FIGS. 11, 12C and 16, another method of communication between the host processor 300 and the sensor controller 200 is described, which includes generally five steps. In step S1205 of FIG. 12C, the host processor 300 transmits a command 121 issued by an application (302 in FIG. 11) operating on the host processor 300 to the sensor controller 200. In step S1206, the sensor controller 200 receives and forwards the command 121 to the active stylus 100. For example, the sensor controller 200 may include the command in any signal (e.g., beacon signal) the sensor controller 200 transmits to the active stylus 100. In step S1207, the active stylus 100, in response to the command 121, operates on the command 121 and transmits a command response 123 to the sensor controller 200. For example, the active stylus 100 may include the command response in any signal (e.g., response signal) the active stylus 100 transmits to the sensor controller 200. In step S1208, the sensor controller 200 stores the command response 123 in its memory. In step S1209, the host processor 300 requests to retrieve the command response 123 from the memory of the sensor controller 200. The method is additionally illustrated in a sequence diagram of FIG. 16. The exchange of the command 121 and the command response 123 between the host processor 300 and the sensor controller 200 is supported by any suitable interface, such as a Universal Serial Bus (USB) interface, or an Inter-Integrated Circuit (I2C) bus, a Serial Peripheral Interface (SPI) bus, or other suitable hardware interface.

The method allows the application 302 operating on the host processor 300 to issue commands to the stylus 100 and receive the results therefrom. The sensor controller 200 forwards a command received from the host processor 300 to the active stylus 100 without interpreting the contents of the command, and receives and stores the command response returned from the active stylus 100 for later retrieval by the application 302 operating on the host processor 300. In various embodiments, the sensor controller 200 forwards the command received from the host processor 300 “as is” to the active stylus 100. For example, when the sensor controller 200 receives a command of N bits from the host processor 300, the sensor controller 200 forwards the command of N bits to the active stylus 100 without any modification or addition. This may be technically advantageous in allowing the application 302 operating on the host processor 300 to issue various comments without regard to the capability (e.g., firmware) of the sensor controller 200 to interpret/process the command on behalf of the active stylus 100. In these embodiments the command 100 needs to be merely operable/actionable by the active stylus 100. This may lead to freedom in designing various (additional) commands that may be employed by the application 302 and also to freedom in introducing various (additional) attributes/features to the active stylus 100 that the application 302 can take advantage of.

Various types of commands may be sent from the application 302 operating on the host processor 300 to the sensor controller 200, to be forwarded onto the active stylus 100.

The command 121 may be a request (or read) command to identify an attribute of the active stylus. For example, the command may request the active stylus 100 to identify its preferred color value, preferred line width value, or preferred line style value. The command response 123 from the active stylus 100 then includes the active stylus's preferred color value, preferred line width value, or preferred line style value. The command response 123 may then be stored in the memory of the sensor controller 200. The application 302 operating on the host processor 300 may thereafter retrieve the stored attributes (e.g., preferred color, preferred line width and/or preferred line style of the active stylus 100) from the memory of the sensor controller 200. As styluses become more widespread there is more likelihood for the same stylus to be used in multiple applications or on multiple systems. When moving between applications or systems it would be more intuitive for the user if the virtual on-screen ink is consistent between these applications and systems. The embodiment of the invention, by allowing the active stylus 100 to indicate its attributes such as its preferred color, line width and/or line style, facilitates the application 302 operating on the host processor 300 to render the virtual on-screen ink consistently in accordance with the user's preference. As further examples, the request command 121 may request the active stylus 100 to identify its battery level, firmware version, stylus version, etc. The active stylus 100 returns a command response 123 including data indicative of its battery level, firmware version, stylus version, etc., which is stored in the memory of the sensor controller 200 for retrieval by the host processor 300.

In some embodiments, the active stylus's attributes, such as its preferred color, preferred line width and/or line style, are read only and not changeable by the sensor controller 200. This may be the case, for example, when the active stylus has a physical ink having a color that matches the preferred color, or when the preferred color is set by the user with selector switches.

In other embodiments, the active stylus's attributes may be (forcibly) set or configured by the sensor controller 200. To this end, the sensor controller 200 may send a setting command 121 to set an attribute for the active stylus, such as its preferred color value, preferred line width value, or preferred line style value. The application 302 operating on the host processor 300 issues the setting command 121 to the sensor controller 200, which is then forwarded to the active stylus 100. The active stylus 100, upon receipt of the setting command 121, sets its attributes according to the setting command 121, and sends a command response 123 including a flag indicating that the operation requested by the setting command 121 has been successfully carried out (i.e., the preferred color, preferred line width and/or preferred line style has been successfully set).

In further embodiments, the application 302 operating on the host processor 300 may issue a command 121 that requests the active stylus 100 to transmit downlink signals (including stylus attributes, for example) in a defined format. The defined format may dictate at least one of a transmission frequency and a transmission time length for use by the active stylus 100 to transmit downlink signals. The sensor controller 200 forward such command 121 to the active stylus 100, which sends downlink signals in the defined format specified by the command 121 as part of, or outside, a command response 123. For example, the active stylus 100 sends downlink signals using the transmission frequency and/or the transmission time length (time duration) specified by the command 121.

In still further embodiments, the application 302 operating on the host processor 300 may issue a command 121 that requests the active stylus 100 to perform a defined operation that derives data. For example, the command 121 may request the active stylus 100 to run a diagnostic test. Such “diagnostic” command may be considered as one type of “request” command. The active stylus 100, upon receipt of such command 121, runs the requested diagnostic test and returns the test results data to the sensor controller 200 as part of, or outside the command response 123. The returned data is then stored in the memory of the sensor controller 200 for later retrieval by the application 302 operating on the host processor 300.

In further embodiments, the application 302 operating on the host processor 300 may issue a command 121 that directs the active stylus 100 to adjust its pressure curve to more closely follow a force response curve of a traditional marking tool (e.g., pencil, roller ball pen) having a line style that the active stylus 100 is configured to mimic.

The tip pressure data reported by the stylus 100 is the result of a force applied to the stylus tip as measured by a force sensor. The relationship between the applied force and reported pressure value, referred to as the “pressure curve,” is typically linear or logarithmic in nature.

With traditional marking tools, such as a pencil or roller ball pen, there is a relationship between the applied force and visual result, referred to as the “force response curve.” The force response curve differs for each marking tool, and may be different than the pressure curve of the stylus configured to mimic the particular style of a marking tool (e.g., pencil, roller ball pen). For example, a pencil has a more linear force response curve that responds to a range of applied forces with lighter and darker lines, whereas a roller ball pen has a very steep force response curve where additional applied force has little effect on the line drawn. It may therefore be technically advantageous to modify the pressure curve of the stylus to better match the force response curve of a traditional marking tool that the stylus is configured to mimic.

In order to match the stylus pressure curve to the force response curve of a traditional marking tool, it is necessary to know what marking tool the user wishes to use. Due to the introduction of the preferred line style value according to various embodiments of the invention as described above, the application 302 operating on the host processor 300 may determine the particular line style intended for the active stylus 100 by the user. For example, the application 302 may send a request command 121 to request the active stylus 100 to return the line style value set in the active stylus 100 (by the user, for example). Alternatively the application 302 may send a setting command (line style command) 121 to forcibly set a particular line style value in the active stylus 100. In various exemplary embodiments, based on the marking tool specified in the line style command 121, the active stylus (automatically) adjusts the pressure curve to more closely approximate the force response curve of the marking tool corresponding to the specified line style value. For example, when the line style value of the active stylus 100 is set for “pencil,” the active stylus 100 is directed to adjust its pressure curve to more closely follow the force response curve of a pencil. In these embodiments, a single command that (forcibly) sets a particular line style value for the active stylus 100 may additionally direct the active stylus 100 to adjust its pressure curve to follow the force response curve corresponding to the set line style value.

The various embodiments described above can be combined to provide further embodiments, and aspects of the embodiments can be modified based on the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. 

The invention claimed is:
 1. A method of communication between an application running on a host processor and an active stylus via a sensor controller, the sensor controller coupled to a sensor configured to interact with the active stylus, the method comprising: the application running on an Operating System running on the host processor, configured to send a command whose protocol is pre-shared between the application and the active stylus but not shared between the application and the sensor controller, the command being included in an N bit data formed by the host processor; the host processor running the Operating System and the application, and transmitting the N bit data including the command provided from the application; the sensor controller receiving the N bit data including the command from the host processor and forwarding, without interpreting the N bit data, the command to the active stylus; the active stylus, (a) in response to the command which is not correctly received, not executing the command and not transmitting a command response to the sensor controller; and (b) in response to the command which is correctly received, (i) executing the command according to the protocol pre-shared with the application; (ii) obtaining a status data indicating whether the command has been successfully executed internally in the active stylus or not; and (iii) transmitting the status data regarding the command to the sensor controller; the sensor controller storing the status data received from the active stylus in a memory device; and the host processor requesting to retrieve the status data from the memory device of the sensor controller and the application obtaining the status data.
 2. The method of claim 1, wherein the sensor controller and the host processor are configured to be connected via a Universal Serial Bus (USB) interface.
 3. The method of claim 1, wherein the sensor controller and the host processor are configured to be connected via an Inter-Integrated Circuit (I2C) bus or a Serial Peripheral Interface (SPI) bus.
 4. The method of claim 1, wherein the command is a request command to identify an attribute of the active stylus.
 5. The method of claim 4, wherein the command requests the active stylus to identify one or more of its preferred color value, preferred line width value, and preferred line style value.
 6. The method of claim 1, wherein the command is a setting command to set an attribute for the active stylus.
 7. The method of claim 6, wherein the command sets for the active stylus one or more of a preferred color value, a preferred line width value, and a preferred line style value.
 8. The method of claim 7, wherein the command to set a preferred line style value for the active stylus additionally adjusts the active stylus's pressure curve to more closely follow a force response curve of a traditional marking tool having a line style that corresponds to the preferred line style value set in the command.
 9. The method of claim 1, wherein the command requests the active stylus to transmit downlink signals in a defined format.
 10. The method of claim 9, wherein the defined format dictates at least one of a transmission frequency and a transmission time length for the active stylus to use to transmit downlink signals.
 11. The method of claim 1, wherein the status data includes data derived as a result of executing the command.
 12. A sensor controller to be coupled to a sensor and to a host processor, the sensor including a matrix of electrodes to receive signals from and transmit signals to an active stylus, the sensor controller comprising: reception circuitry which, in operation, receives from the host processor an N bit data including a command provided from an application running on an Operating System running on the host processor, wherein a protocol of the command is pre-shared between the application and the active stylus but not shared between the application and the sensor controller; a memory device; and processing circuitry coupled to the reception circuitry and the memory device, wherein, the processing circuitry, in operation, forwards, without interpreting the N bit data, the command, via the matrix of electrodes of the sensor, to the active stylus, receives, via the matrix of electrodes of the sensor, from the active stylus, a status data indicating whether the command, which is correctly received by the active stylus, has been successfully executed internally in the active stylus according to the protocol pre-shared between the application and the active stylus, stores the received status data in the memory device, and in response to a retrieval request from the host processor, returns the status data to the host processor so that the application obtains the status data.
 13. The sensor controller of claim 12, configured to connect with the host processor via a Universal Serial Bus (USB) interface.
 14. The sensor controller of claim 12, configured to connect with the host processor via an Inter-Integrated Circuit (I2C) bus or a Serial Peripheral Interface (SPI) bus.
 15. A host processor, comprising: transmission circuitry which, in operation, transmits an N bit data including a command provided from an application running on an Operating System running on the host processor to a sensor controller coupled to a sensor configured to interact with an active stylus, wherein a protocol of the command is pre-shared between the application and the active stylus but not shared between the application and the sensor controller; processing circuitry coupled to the transmission circuitry, the processing circuitry configured to request retrieval of a status data, which is returned from the active stylus and stored in a memory device of the sensor controller, the status data indicating whether the command has been successfully executed internally in the active stylus according to the protocol pre-shared between the application and the active stylus; and reception circuitry which, in operation, receives the status data retrieved from the memory device of the sensor controller so that the application obtains the status data.
 16. The host processor of claim 15, configured to connect with the sensor controller via a Universal Serial Bus (USB) interface.
 17. The host processor of claim 15, configured to connect with the sensor controller via an Inter-Integrated Circuit (I2C) bus or a Serial Peripheral Interface (SPI) bus.
 18. The host processor of claim 15, wherein the command is a request command to identify an attribute of the active stylus.
 19. The host processor of claim 18, wherein the command requests the active stylus to identify one or more of its preferred color value, preferred line width value, and preferred line style value.
 20. The host processor of claim 15, wherein the command is a setting command to set an attribute for the active stylus.
 21. The host processor of claim 20, wherein the command sets for the active stylus one or more of a preferred color value, a preferred line width value, and a preferred line style value.
 22. A system, comprising: (a) a host processor running an application and an Operating System and configured to transmit an N bit data including a command provided from the application, wherein a protocol of the command is pre-shared between the application and an active stylus but not shared between the application and a sensor controller, (b) the active stylus configured to interact with a sensor, and (c) the sensor controller coupled to the sensor and including: sensor reception circuitry which, in operation, receives the N bit data including the command from the host processor; a memory device; and sensor processing circuitry coupled to the sensor reception circuitry and the memory device and configured to forward, without interpreting the N bit data, the command to the active stylus, wherein, the active stylus, (a) in response to the command which is not correctly received, does not execute the command and does not transmit a command response to the sensor controller; and (b) in response to the command which is correctively received, (i) executes the command according to the protocol pre-shared with the application, (ii) obtains a status data indicating whether the command has been successfully executed internally in the active stylus or not, and (iii) transmits the status data regarding the command to the sensor controller; and the sensor controller stores the status data in the memory device and, in response to a retrieval request from the host processor, returns the status data to the host processor so that the application obtains the status data. 